Subscriber
Subscriber
RELEASE 22.2.R1
Where consecutive timeouts are defined by the number of retries configured below
the RADIUS server policy servers.
If, for example, the RADIUS server has “2 timeouts, 1 reply, 1 timeouts”, whereby the
timeouts are originated for the same host, the server is not marked down since
intermediate replies were received.
For example,
configure
subscriber-mgmt
authentication-policy "auth-policy-1" create
radius-server-policy "aaa-server-policy-1“
exit
exit
Note:
• To avoid conflicts, the following CLI commands are ignored in the authentication policy
when a radius-server-policy is attached:
- All commands in the radius-authentication-server context
- accept-authorization-change
- coa-script-policy
- accept-script-policy
- request-script-policy
• The fallback-action command specifies the action when no RADIUS server is
available is configured direct in the config>subscr-mgmt>auth-plcy CLI context.
For example:
configure
subscriber-mgmt
radius-accounting-policy "acct-policy-1" create
radius-server-policy "aaa-server-policy-1“
exit
exit
Note: To avoid conflicts, the following CLI commands are ignored in the RADIUS
accounting policy when a radius-server-policy is attached:
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
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
Note: To configure RADIUS CoA servers for use in Enhanced Subscriber Management, the
server must be configured in the corresponding routing instance with the accept-coa
command enabled.
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
Note: In a legacy RADIUS server configuration, to configure RADIUS CoA servers for use
in Enhanced Subscriber Management, the server must be configured in the authentication
policy with the accept-authorization-change command enabled. A CoA only server can be
configured with the optional coa-only flag.
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
Note: In the TPSDA solutions, the Nokia 5750 Subscriber Services Controller (SSC) serves
as the policy manager, DHCP and RADIUS server.
In this application, one of the required functions can be to authenticate users trying
to gain access to the network. While sometimes the DHCP server (an SSC) can
perform authentication, in most cases a RADIUS server (an SSC) is used to check
the customer's credentials.
Note: See the DHCP Management section for information about DHCP and DHCP
Snooping.
For information about the RADIUS server selection algorithm, refer to the 7450 ESS,
7750 SR, 7950 XRS, and VSR System Management Guide.
A typical initial DHCP scenario (after client bootup) is shown in Figure 67.
discover
offer
request
ack
triple play 1
But, when the client already knows its IP address (when an existing lease is being
renewed), it can skip straight to the request/ack phase, as shown in Figure 68.
Figure 69 shows a flow of RADIUS authentication of DHCP hosts in the triple play
aggregation environment. Besides granting the authentication of given DHCP host,
the RADIUS server can include RADIUS attributes (standard and/or Vendor-Specific
Attributes (VSAs)) which are then used by the network element to provision objects
related to a given DHCP host.
DHCP
server
RADIUS
DSLAM server
7450 /
7750
GE
BRAS 1
VoIP edge
7450 ESS 7450 /
7750
BRAS 2
VoIP edge
OSSG112
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.
To comply with RFC 4679, DSL Forum Vendor-Specific RADIUS Attributes, the
software includes the following attributes in the authentication-request message:
• actual-data-rate-upstream
• actual-data-rate-downstream
• minimum-data-rate-upstream
• minimum-data-rate-downstream
• access-loop-encapsulation
When the node is configured to insert (or replace) Option 82, the above mentioned
attributes do have the content after this operation has been performed by the
software.
These are only be included in the access-request if they have been configured.
To provide the possibility to push new policies for currently active subscribers, the
routers support commands to force re-authentication of the given subscriber-host.
After issuing such a command, the router sends a DHCP FORCERENEW packet,
which causes the subscriber to renew its lease (provided it supports force-renew).
The DHCP request and ACK are then authenticated and processed by the routers as
they would be during a normal DHCP renew.
9.2.2.1 Calling-Station-ID
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).
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 (Table 12):
Only one of the above attributes to specify a session timeout can be present in a
single RADIUS message. An event is raised when both are specified in a single
message.
The output of the show service id service-id ppp session detail CLI command
contains following fields related to session timeout for PPP sessions:
The output of the show service id service-id dhcp lease-state detail CLI command
contains following fields related to session timeout for DHCPv4 hosts:
• 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
Note: In a radius-proxy scenario or when a DHCPv4 host is created with a RADIUS CoA
message, the RADIUS attribute [26-6527-174] Alc-Lease-Time attribute must be used to
specify the lease time. If the [26-6527-174] Alc-Lease-Time is not present in these
scenarios, then the RADIUS attribute [27] Session-Timeout is interpreted as DHCPv4 lease
time.
In many networks, the user name has specific meaning with respect to the domain
(ISP) where the user should be authenticated. To identify the user correctly, the user
name in an authentication-request message should contain a domain-name. The
domain-name can be derived from different places. In PPPoE authentication the
domain name is given by the PPPoE client with the user name used in PAP or CHAP
authentication. For DHCP hosts similar functionality is implemented by a “pre-
authentication” lookup in a local user database before performing the RADIUS
request.
For example, it can be derived from option60 which contains the vendor-specific
string identifying the ISP the set-box has been commissioned by.
To append a domain name to a DHCP host, the following configuration steps should
be taken:
• Under the (group or IP) interface of the service, a local user database should be
configured in the DHCP node and no authentication policy should be configured.
• In the local user database, there should be a host entry containing both the
domain name to be appended and an authentication policy that should be used
for RADIUS authentication of the host. The host entry should contain no other
information needed for setting up the host (IP address, ESM string), otherwise
the DHCP request is dropped.
• In the authentication policy, the user-name-format command should contain
the parameter append domain-name.
SHCV policies are used to control subscriber host connectivity verification which
verifies the host connectivity to the BNG. There are two types of SHCV: periodic and
event triggered. Prior to Release 13.0R4, some event triggered SHCV relied on the
reference timer set by the host-connectivity-verify under the group interface while
others had hard-coded values. Release 13.0R4 introduced the SHCV policy that
allows individual configuration of trigger SHCV timers and periodic SHCV timers
depending on the application.
• ip-conflict — This SHCV is sent when a SAP detects that there is a IP address
or prefix conflict on the SAP.
• 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.
Some SHCVs are triggered based on a host’s DHCP messages. These DHCP
messages are not buffered. The SHCV is used only to perform a verification check
on an old host to verify if the host is still connected to the BNG. Therefore, the BNG
still requires the new hosts to retransmit their DHCP messages once the SHCV
removes the disconnected host.
RADIUS requests from a particular subscriber are always forwarded to the same
RADIUS server. When a server replies to a RADIUS request, it transitions from the
operational state of “unknown” to “in-service”. A server may transition from
“unknown” to “out-of-service” if the server fails to respond to the initial RADIUS
message.
start
Server configuration
unknown
RADIUS reply
RADIUS reply
in-service
No
RADIUS Down-timeout expires
reply
Reply timeout
out-of-service probing
Hold-down-time expires
0927
Note: It is highly recommended that the down-timeout command be set to its default value,
which is no down-timeout.
The down-timeout default value is the timeout value multiplied by the number of
retry attempts. The timeout value is the time that the router waits for the RADIUS
server to reply, and the retry value is the number of attempts the 7750 SR makes to
contact the RADIUS server. If the RADIUS server remains unresponsive, the timer
continues to increment until it reaches the configured down-timeout value and the
server is declared “out-of-service”.
For RADIUS servers that do not respond to all RADIUS requests, a test user account
can be optionally set up to periodically send RADIUS request messages to keep the
server in service. Typically, a RADIUS server should always respond to all access
requests. However, creating a test user account for periodic keep-alive may place an
unnecessary load on the processor and may lower the overall scale of the router.
At the start of the out-of-service state, a hold-down-time timer starts. The timer
holds down the RADIUS server and prevents it from operating; no RADIUS
messages are sent to an out-of-service server. This is beneficial for the following
reasons.
After the hold-down-time timer expires, the server enters into the “probing” state.
There must be multiple RADIUS servers and at least one healthy server for the
server to enter the probing state. Probing is always performed by the test user
account; actual subscriber requests are never used during probing. If no test user
account exists, an actual subscriber request is used to perform the probe. There are
no retry attempts; only a single RADIUS message is used to probe a RADIUS server.
If the RADIUS server responds, it is declared “in-service” immediately. If the RADIUS
server fails to respond within the timeout value, it is declared “out-of-service” again
and the hold-down-time timer restarts. Subscriber RADIUS messages used for
probing are not cached, and if the server fails to respond, the subscriber is required
to send the RADIUS message again by sending an address request; for example,
DHCP, PPP, or Stateless Address Auto-Configuration (SLAAC) or by performing a
data-trigger.
Typically, when using the direct access algorithm, the primary server (lowest
configured server index) serves all RADIUS request messages. The other RADIUS
servers are used for backup purposes only and might be using a lighter-weight
processor. Therefore, it is best to revert to the primary server as soon as it is
restored. This can be accomplished by disabling stickiness in direct mode; the
RADIUS accounting messages are forwarded to the primary server once it is
restored.
Both accept and user-db can be combined with the force-probing command.
Force-probing forces the out-of-service server to transition to the probing state
immediately, bypassing the hold-down-time timer. Force-probing is a mechanism to
promptly restore connectivity to a RADIUS server. A test user is not used to perform
a force probe; only actual subscriber authentication is used to test the operating state
of the RADIUS server. Probing only occurs when a server is out of service. If all
servers are in the probing state, all new incoming authentication requests follow the
fallback action immediately.
When probing with an actual subscriber authentication, the 7750 SR only waits for a
reply for one timeout interval without any retries. During the wait, the server is in a
probing state and no other subscribers are used to probe this server. The subscriber
authentication request is not cached when used for probing. Therefore, to trigger
authentication again, the subscriber is required to authenticate again with an address
request or a data-trigger packet.
Typically, a RADIUS server always responds to all RADIUS requests, and therefore
it is not recommended that a test user account be used unless it is absolutely
required for certain types of servers. The test user account creates extra load for the
processor and can affect scaling. The test user account can be used with a python
script (for example, adding additional attributes to the test user account during an
access-request operation).
• subscriber-id-string
• subscriber-profile-string
• sla-profile-string
• ancp-string
• intermediate-destination-identifier-string
• application-profile-string
When RADIUS authentication response messages contain the above VSAs, the
information is used during processing of DHCP-ACK message as an input for the
configuration of subscriber-host parameters, such as QoS and filter entries.
If ESM is enabled and the RADIUS response does not include all ESM-related VSAs
(an ANCP string is not considered as a part of ESM attributes), only the subscriber-
id is mandatory (the other ESM-related VSAs are not included). The remaining ESM
information (sub-profile, sla-profile) is extracted from DHCP-ACK message
according to normal flow (Python script, and so on).
If the profiles are missing from RADIUS, they are not extracted from the DHCP data
with Python to prevent inconsistent information. Instead, the data reverts to the
configured default values.
However, if the above case, a missing subscriber ID causes the DHCP request to be
dropped. The DHCP server is not queried in that case.
These attributes are accepted only if the system is explicitly configured to perform
DHCP-server functionality on a given interface.
config>service>vprn>radius-server#
server "coa-1" address 10.1.1.1 secret <shared-secret> hash2 create
accept-coa
exit
The UDP port for CoA and Disconnect Messages is configurable per system
with the command:
config>aaa#
radius-coa-port {1647|1700|1812|3799}
Note: There is a priority in the functions that can be performed by CoA. The first matching
one is performed:
There are several reasons for using RADIUS initiated CoA messages:
If the changes to ESM attributes are required, the RADIUS server sends CoA
messages to the network element requesting the change in attributes included in the
CoA request:
• Alc-Ipv6-Address
• Framed-Ipv6-Prefix
• Delegated-Ipv6-Prefix
• Alc-Client-Hardware-Addr (Required for private-retail subnet. For more
information, refer to 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, refer to 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 given host.
• 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
• 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 given subscriber host. Obviously, 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 hence NAK response), the element includes the error code in accordance with
RFC 3576 definitions if an appropriate error code is available.
- 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
given 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 given 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.
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.
A CoA can be triggered through the CLI by using a tools command that does not
require a RADIUS authentication policy. The tools command can also be used to
spoof a CoA from a configured server for purposes such as testing CoA python
scripts. However, when spoofing the CoA from a RADIUS server, the configuration
of a RADIUS authentication policy is required.
SNMP can also trigger the tools CoA command. However, SNMP cannot execute
the command when it is referencing an on-board flash file. To execute from a file, the
file must be non-local, such as using a URL specifying the location of the file on an
FTP server.
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.
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:
[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
[42] Acct-Input-Octets
[43] Acct-Output-Octets
[47] Acct-Input-Packets
[48] Acct-Output-Packets
[52] Acct-Input-Gigawords
[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
• NAS-identifier
• alc-subscriber-profile-string
• Accounting-session-id
• Event-timestamp
• 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 given subscriber host
regardless the node used for forwarding.
For RADIUS-based accounting, a custom record can be defined to refine the data
that is sent to the RADIUS server. Refer to the “Configuring an Accounting Custom
Record” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management
Guide for further information.
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)):
term_cause = alc.radius.attributes.get(TERM_CAUSE)
term_cause = struct.unpack('!i', term_cause)[0]
This section is applicable to the 7750 SR or the 7450 ESS. There are three basic
accounting models:
• Per queue-instance
• Per Host
• Per Session
The difference between the three basic accounting models is in its core related to the
processing of the acc-session-id for each model. The differences are related to:
The counters for volume-based accounting are collected from queues or policers that
are instantiated per SLA profile instance (SPI). This is true regardless of which model
of accounting (or combination of models) is deployed. Within the accounting context,
the SPI equates to queue-instance.
The following table summarizes the key differences between various accounting
modes of operation that are supported. Interim-updates for each individual mode can
be enabled or disabled through configuration (interim-update keyword as an
extension to the commands that enable three basic modes of accounting). This is
denoted by the IU-Config keyword under the ‘I-U’ column in the table. The table also
shows that any two combinations of the three basic models (including their variants
for volume and time- based accounting) can be enabled simultaneously.
session
host
host
host-accounting queue-
instance
session
host
session-accounting + queue-
host-accounting instance
Note: Hosts within the targeted CoA entity are affected as follows:
• If the CoA target is the session, both constituting members (IPv4 and IPv6) of the dual-
stack host are affected.
• If the CoA target is the queuing-instance, up to 32 hosts that are sharing that SPI are
affected.
The following are the properties of the per queue-instance accounting model:
• A RADIUS accounting start message is sent when the queue instance (SLA
profile instance) is created. It contains the IP address attribute of the host that
caused the queue instance (SLA profile instance) to be created.
• Additional hosts may bind to the queue instance (SLA profile instance) at any
time, but no additional accounting messages are sent during these events.
• If the original host disconnects then future accounting messages use an IP
address of one of the remaining hosts.
• When the final host associated with a queue instance (SLA profile instance)
disconnects an Accounting Stop message is sent.
In the per host accounting mode of operation the accounting message stream
(START/INTERIM-UPDATE/STOP) is generated per host.
The following are the properties of the per host accounting model:
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:
• 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.
Table 15 outlines the RADIUS accounting behavior based on the session type and
the next-hop host.
Session Type and Next- RADIUS Accounting RADIUS Accounting RADIUS Accounting
Hop Host Start Interims Stop
PPP session with IPv6 A PPP connection A DHCP NA+PD solicit A PPP disconnect with
PD pointing to IPv4 host triggers an accounting triggers an interim update only the IPv4 and IPv6 PD
as the next hop start for the PD host with host triggers an
interim reason accounting stop with the
“delegated-ipv6-prefix- prefix included in the VSA
up” and the prefix Framed-IPv6-Route
included in the VSA Caveat
Framed-IPv6-Route • A PPP disconnect
A DHCP PD solicit with the IPv4, NA,
triggers an interim update and PD host without
for the PD host with session-optimized-
interim reason delegated- stop enabled, is not
ipv6-prefix-up and the include the VSA
prefix included in the VSA Framed-IPv6-Route
framed-ipv6-route
Caveat
• A DHCP PD lease
expire triggers an
interim update with
interim reason
“delegated-ipv6-
prefix-down”;
however, the VSA
framed-ipv6-route is
not included
PPP session with IPv6 A PPP connection A DHCP NA+PD solicit A PPP subscriber
PD pointing to IPv6 NA triggers an accounting triggers an interim update disconnect triggers an
host as the next hop start. It is possible to have for the PD host with accounting stop with the
a single-stack IPv6-only interim reason delegated- PD host prefix included in
session ipv6-prefix-up and the the VSA Framed-IPv6-
prefix included in the VSA Route
framed-ipv6-route
Caveat
• A DHCP PD lease
expire triggers an
interim update with
interim reason
“delegated-ipv6-
prefix-down”;
however, the VSA
FramedIPv6-Route
is not included
Session Type and Next- RADIUS Accounting RADIUS Accounting RADIUS Accounting
Hop Host Start Interims Stop
IPoE session with IPv6 A DHCPv4 or a DHCPv6 A DHCP PD is always If only the IPv4 host and
PD pointing to IPv4 host request (DHCPv6 always performed together with PD host remain, the
as the next hop performs NA and PD NA. The PD is not in the release of the DHCPv4
requests together) start message but is triggers an accounting
triggers the accounting included in the accounting stop with the PD host
start interim update as a part of prefix included in the VSA
the host update. Framed-IPv6-Route
If the DHCPv4 lease Caveat
expires, the interim • If the DHCPv4 is
update contains the PD released and an
prefix in the VSA framed- IPv6 NA host
ipv6-route remains, the IPv6
Caveat lease release/expire
• A DHCP PD lease is an interim update
expire triggers an that does not include
interim update with the prefix
interim reason
“delegated-ipv6-
prefix-down”;
however, the VSA
Framed-IPv6-Route
is not included
IPoE session with IPv6 A DHCPv4 or a DHCPv6 A DHCP PD is always If only the IPv6 subscriber
PD pointing to IPv6 NA request (DHCPv6 always performed together with is left, the release of NA
host as the next hop performs NA and PD NA. The PD is not in the contains the prefix of the
requests together) start message but is PD host
triggers the accounting included in the accounting Caveat
start. It is possible to have interim update as a part of • If the DHCPv6 is
a single-stack IPv6-only the host update. released and an
session Caveat IPv4 host remains,
• A DHCP PD lease the IPv6 lease
expire triggers an release/expire is an
interim update with interim update that
interim reason does not include the
“delegated-ipv6- prefix
prefix-down”;
however, the VSA
Framed-IPv6-Route
is not included
In SR OS, the accounting paradigm is based on SLA profile instances yet this is at
odds with traditional RADIUS authentication and accounting which is host-centric. In
previous SR OS releases, it was possible to have many hosts sharing a common
SLA profile instance, and thus accounting and QoS parameters. Complications
would arise with RADIUS accounting because Accounting-Start and Accounting-
Stop are a function of sla-profile instance and not the hosts. This meant that some
host-specific parameters (like framed-ip-address) would not be consistently included
in RADIUS accounting.
Currently, dual-stack subscribers are really two different hosts sharing a single sla-
profile instance. A new RADIUS accounting mode has been introduced to support
multiple-host environments.
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 value of zero sends the Accounting Interim Update message without introducing
an additional random delay.
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
User identification is used to correlate RADIUS accounting messages with the given
user. During the authentication process, the RADIUS authentication server inserts a
class attribute into the RADIUS authenticate response message and the router
echoes this class attribute in all RADIUS accounting messages.
The 7750 SR can store up to six class attributes for both RADIUS and NASREQ.
Each class VSA or AVP can have a maximum of 253 characters. If the VSA or AVP
contains more than 253 characters, only the first 253 characters is stored. If there are
more than six VSAs or AVPs, only the first six is stored. This functionality is also
applicable to RADIUS authentication by the ISA.
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.
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:
Use the following CLI command to display the Accounting On/Off information for a
radius-server-policy:
The operational state provides following state information: The sending of the
Accounting-On or Accounting-Off message is ongoing (sendAcctOn, SendAcctOff),
is successfully responded (on, off) or no response received (OffNoResp).
The Session-Id is a unique identifier for each RADIUS server policy accounting
Accounting-On/Accounting-Off sequence.
The Trigger field shows what triggered the Accounting On or Accounting Off
message. If the radius-server-policy is part of an acct-on-off group then the group
name is shown in brackets.
The server field shows which server in the RADIUS server policy responded to the
Accounting-On or Accounting-Off message.
===============================================================================
Idx Name Address Port Oper State
Auth/Acct
-------------------------------------------------------------------------------
1 server-3 172.16.1.10 1812/1813 unknown
===============================================================================
-------------------------------------------------------------------------------
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.
config
aaa
radius-server-policy "aaa-server-policy-1" create
servers
router "Base"
buffering
acct-start min 60 max 3600 lifetime 12
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:
a. RADIUS accounting response is received, or
b. the lifetime of the buffered message expires (as shown in Figure 71), or
c. (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, or
d. the message is manually purged from the message buffer with a clear
command
Message
Removed
from Buffer
Time
Lifetime
Minimum Maximum Maximum
Buffer Interval Buffer Interval Buffer Interval
al_0173
Use the following clear command to manually delete messages from the RADIUS
accounting message buffer:
When specifying the account session ID, only that specific message is deleted from
the message buffer. If no account session ID is specified, all messages for that
RADIUS server policy are deleted from the message buffer.
Use the following show commands to display the RADIUS accounting message
buffer statistics:
Use following clear command to reset the RADIUS accounting message buffer
statistics:
Use the following tools commands to display the RADIUS accounting message
buffer content:
For example:
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.
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
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.
Enhanced Subscriber Management in the 7450 ESS and 7750 SR supports many
vendor's access nodes and network aggregation models, including VLAN per
customer, per service or per access node.
The system can switch between standard and enhanced subscriber management
modes on a per SAP basis. The Enhanced Subscriber Management mode is
supported on the SR-7 and SR-12 chassis and on the ESS-7 chassis.
Some functions are common between the standard and enhanced modes. These
include DHCP lease management, static subscriber host definitions and anti-
spoofing. While the functions of these features may be similar between the two
modes, the behavior is considerably different.
- 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 proper
enhanced mode operation. If any one of the following requirements is not met,
enhanced mode operation is not allowed on the SAP:
When the router successfully enables the enhanced mode, the current dynamic
subscriber hosts are not touched until a DHCP message event occurs that allows re-
population of the dynamic host information. Thus, over time, the dynamic subscriber
host entries are moved from SAP-based queuing and SAP-based filtering to
subscriber-based queuing and filtering. In the event that a dynamic host event cannot
be processed due to insufficient resources, the DHCP ACK message is discarded
and the previous host lease information is retained in the system.
manually configure the set of QoS, security, AAA or anti-spoofing functions that
relate to a particular billable entity or subscriber. Subscriber management is typically
centralized and highly integrated with the element, services and middleware
management functions for streamlined management, flowthrough provisioning, and
accelerated service activation, with minimized operating expenditures.
Subscriber Policy Enforcement — The set of actual enforcement functions that are
implemented relative to a given subscriber, possibly at multiple enforcement points
in the infrastructure and as a result of a match between the subscriber profile which
was defined by the subscriber management suite (5750 SSC) and actual traffic
patterns. Examples include for instance, the shaping, policing or rate limiting of traffic
or the traffic of a given subscriber being dropped because it matched or violated any
specific rule (packet with a mismatch between MAC and IP address suggesting an
address spoof for instance).
A host can be an end-user device, such as a PC, VoIP phone or a set top box, or it
can be the user’s Residential Gateway (RGW) if the RGW is using Network Address
Translation (NAT).
A subscriber (in the context of the router) is a collection of hosts getting common
(overall) treatment. It is expected that this group of hosts originate from the same site
and all hosts of a subscriber are reached by the same physical path (such as a DSL
port).
Depending on the network model, hosts associated with a single subscriber can be
associated with a single subscriber SAP or spread across multiple subscriber SAPs
on the same port.
The subscriber identification policy contains the URL definitions for the
Programmable Subscriber Configuration Policy (PSCP) scripts used for DHCP ACK
message processing. Up to three URLs can be defined per subscriber identification
policy. These are designated as primary, secondary and tertiary. Each URL can be
individually enabled or disabled. Only one script (the URL with the highest priority
active script) is used at any one time to process DHCP ACK messages. If the system
detects an error with a specified script, the URL is placed in an operationally down
state. If the script is shut down, it is placed in an administratively down state. A script
that is operationally or administratively down is considered inactive. The system
automatically reverts to the highest priority active script. If a script becomes
operationally down, it must be cycled through the administratively down then
administratively up states for the system to attempt to reactivate the script.
Multiple subscriber identification policies are provided for the event that access
nodes (such as DSLAMs) from different vendors are attached to the same router.
Each policy’s active script can be explicitly defined to process the various DHCP
message formats or idiosyncrasies of each vendor.
Each subscriber identification policy can also contain a subscriber profile map and/
or an SLA profile map. The subscriber profile map creates a mapping between the
sub-profile-strings returned from the active script with an existing subscriber profile
name. The SLA profile map is used to create a mapping between the sla-profile-
strings returned from the active script with an existing SLA profile name.
These strings are used to derive the subscriber profile and the SLA profile to be used
for this host See Using Scripts for Dynamic Recognition of Subscribers.
Subscribers are managed by the router through the use of subscriber identification
strings. A subscriber identification string uniquely identifies a subscriber.
The subscriber identification string is the index key to any entry in the active
subscriber table, and thus must always be available. It is derived as follows:
• For dynamic hosts, the subscriber identification string is derived from the DHCP
ACK message sent to the subscriber host.
- The DHCP ACK message is processed by a subscriber identification script
which has the capability to parse the message into an alternative ASCII
string value.
- If enhanced subscriber management is disabled, the default value for the
string is the content of the Option 82 circuit-id and remote-id fields
interpreted as an octet string.
• For static hosts, the subscriber identification string must be explicitly defined
with each static subscriber host.
When multiple hosts are associated with the same subscriber identification string,
they are considered to be host members of the same subscriber. Hosts from multiple
SAPs can be members of the same subscriber, but for proper virtual scheduling to
be performed all hosts of a subscriber must be active on the same IOM.
When the first host (either dynamic or static) is created with a certain subscriber
identification string, an entry is created in the active subscriber table. The entries are
grouped by their subscriber identification string.
The subscriber profile is a template which contains those hierarchical QoS (HQoS)
and accounting settings which are applicable to all hosts belonging to the same
subscriber. These include:
Attempting to delete any subscriber profile (including the profile named ‘default’)
while in use by an existing active subscriber fails.
For the purpose of supporting multiple service types (such as high speed Internet
(HSI), voice over IP (VoIP), video on demand (VoD) and Broadcast TV) for a single
subscriber, the hosts associated with a subscriber can be subdivided into multiple
SLA profiles.
The SLA profile contains those QoS and security settings which are applicable to
individual hosts. An SLA profile acts like a template and can be used by many
subscribers at one time. Settings in the SLA profile include:
If the SLA profile does not explicitly define an ingress or egress QoS policy, the
default SAP ingress or default SAP egress QoS policy is used.
See Determining the SLA Profile for information on how the SLA profile is determined
for dynamic hosts.
9.3.2.1 Models
For PPPoE, the BNG suggests the IPv6CP protocol to the client during the session
setup phase if the appropriate attributes have been returned by the RADIUS server
on authentication. The RADIUS attribute that indicates the setup of a PPPoE host is
Framed-IPv6-Prefix, which should contain a /64 prefix for the client.
When a PPPoE host has successfully completed the IPv6CP negotiation, the BNG
transmits a Router Advertisement to the PPPoE host containing the suggested prefix
and any other options that are configured. The client may use this information to pick
one or more addresses from the suggested prefix; all addresses within the prefix are
forwarded towards the client.
Alternatively, the Recursive DNS Server (RDNSS) option as defined in RFC 6106,
IPv6 Router Advertisement Options for DNS Configuration, can be included in the
IPv6 Router Advertisements for DNS name resolution of IPv6 SLAAC hosts. See
also DNS and NBNS Name Server IP Addresses for Subscriber Sessions.
9.3.2.1.2 PPPoE RG
Initially, a PPPoE RG follows the same procedure as a PPPoE host: the BNG
receives a prefix from RADIUS (in this case through a Delegated-IPv6-Prefix
attribute), which is used as a trigger to suggest the IPv6CP protocol to the client. The
prefix that is suggested to the client should have the same prefix length as configured
under the subscriber>if>ipv6 node (delegated-prefix-length). This length should be
between 48 and 64 bits, inclusive.
After the IPv6CP protocol has completed, however, the client should run the
DHCPv6 protocol over its PPPoE tunnel to receive a Delegated Prefix (IA_PD) and
optionally IPv6 DNS server information. This Delegated Prefix can then be
subdivided by the client and distributed over its downstream interfaces. During
DHCPv6, no extra RADIUS requests are made; the information is stored during the
initial (PPPoE or PPP) authentication until the client starts DHCPv6.
Only after DHCPv6 has completed, the IPv6 subscriber host is instantiated and the
BNG starts sending Router Advertisements (if configured.) The router
advertisements do not contain any prefix information, which has already been
provided by DHCPv6, but it is used as an indication to the client that its default
gateway should be the BNG.
The DHCPv6 protocol handling and Router Advertisement behavior are similar to the
PPPoE RG case above, with the exception that for an IA_NA address, the entire /64
prefix containing the address is allocated to the client.
9.3.2.2 Setup
IPv6 ESM hosts are only supported in the Routed CO model (both VPRN and IES).
At the IPv6 node under the subscriber interface level, the length of the prefixes that
are offered is defined through the delegated-prefix-length option. This setting is fixed
for the subscriber interface and cannot be changed once subscriber prefixes are
defined.
Subscriber prefixes define the ranges of addresses that are offered on this
subscriber interface. By default, only these subscriber prefixes are exported to the
routing protocols to keep the routing tables small. There are three types of subscriber
interfaces:
The subscriber interface prefix can also be provisioned through RADIUS. The
RADIUS VSA Alc-IPv6-Sub-If-Prefix requires a prefix and the prefix type. The prefix
type can be pd, wan, or both. The prefix is then installed on the subscriber interface
where the subscriber is instantiated. The prefix state is tied to the state of the
subscriber. Once the subscriber session ends, the prefix is removed from the
subscriber interface and subsequently from both the FDB and the RIB. This feature
can be used as an alternative to unnumbered subscriber interfaces, where the
subscriber interface prefix does not need to be predetermined. However, by installing
the prefix after authentication, the subscriber interface becomes numbered. In an
unnumbered subscriber interface all subscriber routes are installed whereas in a
numbered subscriber interface only the subscriber interface prefix is advertised,
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.
• 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.
• 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, thus
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.
A 64-bit WAN mode subscriber interface cannot be changed into a 128-bit WAN
mode subscriber interface in real time. To migrate to a 128-bit WAN mode subscriber
interface, the 64-bit WAN mode subscriber interface must be a removed and re-
created. The 64-bit configuration must be copied, shut down, and the configuration
removed. The configuration can be pasted back with the 128-bit mode added to the
subscriber interface. Below are some migration scenarios.
To prepare to migrate PPPoE and IPoE DHCP hosts on MSAPs, perform the
following steps.
1. Create new subscriber and group interfaces for the 128-bit WAN mode.
2. Update the database for the host-related MSAP parameters. This includes AAA
(both RADIUS and Diameter) and LUDB. The updated DB directs subscribers to
the new subscriber and group interface.
A migration can be performed for either PPPoE and LNS hosts or IPoE DHCP-based
hosts. The migration is dependent on subscriber deletion.
For PPPoE and LNS hosts, when a host disconnects their session, the next session
is migrated. To speed up the migration, and depending on the RG capability,
manually clearing the session could trigger the RG to re-connect through PPPoE
immediately, and migrate to the new interface.
When migrating IPoE DHCP-based hosts, Nokia recommends changing both the
current DHCPv4 and DHCPv6 lease time and rebind times to one hour or more. It is
important to migrate only a small sample size to control the number of DHCP renews.
Subscribers are migrated in the following three ways.
• Subsets of subscribers are migrated to the new 128-bit interface without any end
user action. For example, the end user does not need to reset their modem or
RG. The new authentication establishes the host on the new interface. A
maintenance window is not required.
• To migrate the remaining subscribers, enable the drain function on the DHCP
server to stop all DHCP lease renewal. However, the DHCPv4 and DHCPv6
lease for a subscriber might end at different times. When both the DHCPv4 and
DHCPv6 leases end, the subscriber is removed from the system. Depending on
the RG/CM capability, it may send a DHCP request immediately for a new
DHCPv4 and DHCPv6 addresses. The subscriber is now created on the new
128-bit subscriber interface without any action by the end user.
• For any remaining subscribers that have not been migrated, after the migration
window has waited for the one hour lease time, action by the end user may be
required. The operator must shut down both the subscriber interface and group
interface, and clear all remaining hosts from those interfaces. The end user is
then required to manually reboot the RG to send a DHCP discover/solicit.
When migrating IPoE DHCP-based hosts, Nokia recommends changing both the
current DHCPv4 and DHCPv6 lease time and rebind time to one hour or more. It is
also recommended to migrate only a small sample size to control the number of
DHCP renews. After all leases have been changed to a shorter lease time, perform
the following steps to prepare for the migration.
1. Remove the old subscriber and group interfaces. This may require manual
clearing of subscriber sessions.
2. Re-create new subscriber and group interfaces for the 128-bit hosts (including
SAPs).
3. Apply the appropriate AAA (RADIUS and Diameter) and LUDB changes (new
128-bit IPv6 addresses for all hosts), if any.
Following these preparation steps, a migration can be performed for either PPPoE
and LNS hosts or IPoE DHCP-based hosts. The migration is dependent on
subscriber deletion.
For PPPoE and LNS, when hosts disconnect their session, the RG may try to re-
connect by PPPoE immediately and migrate to the new interface.
For IPoE hosts, new subscribers are automatically migrated upon logging in. Some
end customers may be required to manually reboot the RG to send a DHCP discover/
solicit.
1. Remove the existing subscriber interface and recreate the new 128-bit
subscriber interface, group interface, and related parameters. Removing the
existing subscriber interface may require clearing data-triggered subscribers
from the system.
2. Update the AAA (RADIUS or Diameter) or LUDB parameters related to the
MSAP or SAP. If the end-subscriber is assigned a new IP address, all traffic
using the old IP-address is dropped until the new IP address is in use.
3. To complete the migration, the subscriber must send a data packet for
authentication using the new assigned IP address.
9.3.2.4 Behavior
9.3.2.4.1 Dual-Stack
Clients may support both IPv4 and IPv6 simultaneously (dual-stack hosts.) In this
case, one subscriber host entry is created for the IPv4 address family and one for the
IPv6 instance. The scaling limits apply for all entries, regardless of address type.
For DHCP, these subscriber hosts are fully independent (as they are set up through
different protocols), but for PPPoE hosts or RGs, the ESM information in both
subscriber host entries is linked together through the PPPoE session.
Router Advertisement (RA) messages begin immediately after the subscriber host is
instantiated and unsolicited messages are sent in the interval defined in the
configuration. Apart from unsolicited RAs, the client may also send a router
solicitation (RS) to explicitly request the information. RAs are throttled so that they
are not sent more than once every three seconds.
The prefix option inside the RA policy allows independent prefix options for
subscribers that utilize bridge hosts. The bridge hosts can consist of both DHCPv6
and SLAAC, and are represented as stateful and stateless within the policy
respectively. Within the policy, the autoconfig flag is not configurable and is disabled
by default for the DHCPv6 address and enabled by default for SLAAC. For SLAAC
hosts, if the autoconfig flag is enabled inside the RA policy along with the SLAAC
prefix, the autoconfig flag for the DHCPv6 address or prefix is not enabled as a
result. The timers for either SLAAC and DHCPv6 prefixes can also be configured
independently.
The router advertisement policy has a separate configuration for stateless and
stateful operations. The general recommendation is to configure the valid and
preferred lifetimes for longer than the minimum RA interval to ensure the subscriber
has a valid address to use between each RA interval. If this general rule is not
followed, the subscriber can deprecate the SLAAC prefix between each RA interval
and experience service interruptions. As the minimum RA interval is approximately
15 minutes, the valid and preferred lifetime values should be at least 15 minutes.
Shorter valid and preferred lifetime values can impact the system’s scalability. The
stateful RA has a static option and a dynamic option when configuring the valid and
preferred lifetime values. If the static option is used, the valid and preferred lifetime
values should be greater than the RA interval. For the dynamic option, the auto-
lifetimes feature derives the valid and preferred lifetime values from the DHCPv6
lease. Therefore, the RA and DHCPv6 have the same valid and preferred lifetime
values.
SLAAC hosts are assigned prefixes, where the full Global Unicast Address (GUA) is
not known. Regardless of the force-mcast configuration, the destination IP address
for an RA to an SLAAC host is always be a multicast IP address, with one exception.
If the feature allow-multiple-wan-address is enabled and the same host (same
MAC on the same SAP and same device) has a DHCPv6 NA address, the NA
address is used for the unicast RA. The MAC address can either be a multicast or
unicast address, depending on the configuration of force-mcast.
Table 16 outlines the behavior of the system when the RA policy VSA is included in
authentication, CoA, and re-authentication. The RA policy that is sent from RADIUS
may not yet be provisioned in CLI, and therefore may not exist in the system.
BRG An RA policy does not need An RA policy must exist; An RA policy must exist;
to exist. The RA policy otherwise, a NACK is sent otherwise, all VSAs and the
becomes active when a in response to the CoA. RA policy are ignored.
matching RA policy is An SNMP trap is raised.
provisioned.
If an RA policy does not
exist, the RA parameters
configured under the group
interface are used.
Subscriber is An RA policy does not need An RA policy must exist; An RA policy must exist;
session-based (for to exist for the IPv4 host. otherwise, a NACK is sent otherwise, all VSAs and the
example, an IPoE The RA policy becomes in response to the CoA. RA policy are ignored.
session) active when a matching RA An SNMP trap is raised.
policy is provisioned.
ESM IPv6 host creation fails
when a policy does not
exist.
If an RA policy does not
exist, the RA parameters
configured under the group
interface are used.
IPv4 host that is not An RA policy must exist. An RA policy must exist; An RA policy must exist;
session-based Otherwise, the subscriber otherwise, a NACK is sent otherwise, all VSAs and the
setup is rejected. in response to the CoA. RA policy are ignored.
An SNMP trap is raised.
IPoE linking (both An RA policy does not need An RA policy must exist; An RA policy must exist;
session-based and to exist for the IPv4 host. otherwise, a NACK is sent otherwise, all VSAs and the
not session-based) The RA policy becomes in response to the CoA. RA policy are ignored.
active when a matching RA An SNMP trap is raised.
policy is provisioned.
ESM IPv6 host creation fails
when a policy does not
exist.
If an RA policy does not
exist, the RA parameters
configured under the group
interface are used.
For PPPoE clients, changing either the IPv4 or IPv6 information results in both the
v4 and v6 subscriber host being modified (if they are contained within the same
PPPoE session).
The only CoA action that is allowed for IPv6 hosts is a change of ESM strings;
creation of new hosts and forcing a DHCPv6 RENEW is not supported.
9.3.2.5 Delegated-Prefix-Length
The delegated prefix length (DPL) is applicable to subscriber-hosts with IPv6 Prefix
(IA-PD) assigned by the DHCPv6 Server. IPv6 Prefix is more akin to a route then it
is to an IP address. The length of the prefix plays crucial role in forwarding decisions,
antispoofing, and prefix assignment through DHCPv6 pools in the local DHCPv6
Server.
Customer
Segmented
Space
(16 Prefixes in this Case)
al_0124
For example, a DHCPv6 server prefix pool contains an aggregated (configured) IPv6
prefix from which the delegated prefixes are carved out. In Figure 72 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.
• 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.
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.
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:
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.
configure
service ies/vprn
subscriber-interface <ip-int-name>
ipv6
delegated-prefix-length [48 to 64] |
variable
If the DPL is statically provisioned under the sub-if>ipv6 hierarchy, all hosts under
this subscriber interface inherits this fixed DPL. In case that the DPL is provided by
LUDB or RADIUS in addition to static configuration under the subscriber interface
then the LUDB or the RADIUS one not match the DPL that is statically provisioned
under the subscriber-interface. Otherwise, the prefix instantiation in 7450 ESS and
7750 SR fails.
• LUDB
• RADIUS
• DHCP Server
If the delegated prefix length is variable, for each consecutive address allocation
request for the given delegated prefix, the DHCPv6 server allocates the prefix at the
end of the last delegated lease with the same delegated prefix length. This minimizes
the address space fragmentation within the configured prefix.
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.
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.
config>service>vprn>sub-if>grp-if>ipv6>dhcp6# relay ?
config>service>ies>sub-if>grp-if>ipv6>dhcp6# relay ?
- no relay
- relay
The “client-applications” parameter specifies if the Relay Agent can be used for IPoE
(dhcp) or PPP (ppp) hosts.
Optional configuration parameters:
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 CPE's, 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.
• 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
towards the Local DHCPv6 Server. The DHCPv6 proxy is exclusively used as an
interface between the RADIUS Access-Accept or local user database lookup and the
DHCPv6 client in the consumer device.
The use of the DHCPv6 relay or proxy function depends on the attributes returned
from authentication phase (RADIUS or LUDB).
1. DHCPv6 Proxy:
- If only IPv6 address/prefix information 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.
To support all processing for Enhanced Subscriber Management, several tables are
maintained in the router (Figure 73).
n (Always Persistent
Across Reboot)
Subscriber Host Table
(SAP, IP, MAAC, SLA prof inst)
(SAP, IP, MAAC, SLA prof inst)
An entry is created in the active subscriber table when the first host (either dynamic
or static) is created with a certain subscriber identification string. The entries are
grouped by their subscriber identification string.
An entry is created in the SLA profile instance table when the first subscriber host on
a certain SAP is created that uses a certain SLA profile. All subsequent hosts of the
same subscriber on the same SAP that use the same SLA profile are associated with
this entry. When the last host on this SAP, using this SLA profile disappears, the SLA
profile instance is deleted from the table and the associated queues are removed.
SLA profile instances cannot span multiple subscriber SAPs. If subscriber hosts from
the same subscriber exist on multiple SAPs and are associated with the same SLA
profile template, a separate SLA profile instance is created for each SAP.
Fields for each entry in the SLA profile instance table include:
• Active subscriber
• SAP
• SLA profile
• Number of active subscriber hosts that share this instance
An entry is created in the subscriber host table if anti-spoofing is enabled as well as:
• The first host (dynamic or static) with a specific IP and MAC combination is
created. If the anti-spoof is IP only, the MAC address is masked to all 0’s. If anti-
spoof is MAC, only the IP address is 0.0.0.0. All dynamic hosts and static hosts
with the same IP and MAC combination are associated with the same subscriber
host entry. If the anti-spoof type includes IP (IP-only or IP/MAC), there can be at
most two hosts associated with the entry: one dynamic and one static. If the anti-
spoof type is MAC-only, there can be a combination of several dynamic and
static hosts associated with the entry.
• The non-prof-traffic is provisioned. Both IP and MAC address are all 0’s.
• SAP
• IP address
• MAC address
• SLA profile instance (enhanced mode only)
An entry in the DHCP lease state table is created for each dynamic host. Fields for
each entry in the lease state table include:
• Assigned IP address
• Assigned MAC address
• Persistence key
Subscriber
Sub-profile
Sla-profile Sla-profile
OSSG085
When a DHCP ACK is received for a new subscriber host on a particular SAP:
If this is the first host of a subscriber, an HQoS scheduler is instantiated using the
ingress and egress scheduler policies referred to in the subscriber profile. Otherwise,
if the subscriber profile of the new host equals the subscriber profile of the existing
subscriber, the new host is linked to the existing scheduler. If the subscriber profile
is different from the subscriber profile of the existing subscriber, a new scheduler is
created and all the hosts belonging to that subscriber are linked to this new
scheduler. The new subscriber profile does conflict with the subscriber profile
provisioned for a static host or non-sub-traffic under the same SAP.
If this is the first host of a subscriber on a particular SAP using a particular SLA
profile, an SLA profile instance is generated and added to the SLA profile instance
table. This includes instantiating a number of queues, according to the ingress and
egress QoS profiles referred to in SLA profile, optionally with some specific overrides
defined in the SLA profile. Otherwise the host is linked to the existing SLA profile
instance for this subscriber on this SAP.
Note:
• Any QoS and IP filter policies defined on the SAP are still processed even if Enhanced
Subscriber Management is enabled on the SAP. For IPv4 traffic that is dropped due to
anti-spoofing, counters, logging, and mirroring can be used. All other Layer 2 traffic that
is never blocked by anti-spoofing can be processed by applying a QoS policy on the
SAP and can still be classified differently, by the dot1p value.
• If insufficient hardware resources (queues) or software resources (profile instances)
are available to support the new host, the DHCP ACK is dropped and an event is
generated.
• If there is no entry, this means that the host is not using his 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.
A lockout time per host supports exponential back-off with each retry and failure
cycle, starting with a configured minimum value and increasing up to a configured
maximum. The lockout time can be reset to the configured minimum value if there is
no failed retry within a configured time threshold. The configurable values include:
lockout-reset-time seconds
lockout-time [min seconds] [max seconds]
max-lockout-hosts hosts
If multiple retries/failure cycles occur within the lockout time, then lockout period is
exponentially increased starting from configured minimum value up to the configured
maximum value. The lockout is reset to the minimum value if there is no failed retry
till this lockout time.
This mechanism is supported for both single and dual-stack PPPoE and IPoE
(DHCP) hosts over 1:1 or N:1 static or managed SAPs. The hold-off timer
maintenance is on a per host basis (as follows):
• For 1:1 VLAN (PPPoE or IPoE hosts) per <VLAN, MAC address>
• For N:1 VLAN (PPPoE or IPv4oE hosts) per <VLAN, agent-circuit-id, agent-
remote-id, MAC@>
• For 1:1 VLAN (IPv6oE hosts) per <VLAN, DUID>
A show lockout state for hosts is supported, given one or more of <SAP, MAC@,
agent-circuit-id, agent-remote-id>.
A clear lockout state is supported for hosts given one or more of <SAP, MAC@,
agent-circuit-id, agent-remote-id>.
Any changes in configured lockout values do not apply to hosts currently under
lockout and only applies once these hosts are out of lockout.
9.3.5.1 Functionality
ESM lockout is supported for dual-stack PPPoE hosts, L2TP LAC hosts, dual-stack
IPoE hosts, and ARP hosts. ESM Lockout tracks the following:
The host identification for lockout includes <SAP, MAC@, circuit ID, remote ID>.
9.3.6.1 ANCP
Access Node Control Protocol Management (ANCP) can provide the following
information to the router:
• 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 Enhanced Subscriber Management (ESM), a new string
ancp-string can be returned from the Python script or from RADIUS. If not returned
it defaults to the subscriber ID.
ANCP version 0x31 and 0x32 are both supported and are autodetected at the start
of each ANCP session. Within version 0x32, partitioning is also supported.
Multiple partitions from the same access node are also supported. If partitions are
used, they are automatically detected during the start of an ANCP session.
GSMP
GSMP
OSSG296
In this application ANCP is used between the DSLAM and the router to provide line
control. There are multiple attributes defined as described below. Figure 76 depicts
the connectivity model.
This application is used to communicate the following from the DSLAM to the router
(the policy control point):
• Subscriber rate
• OAM
DSLAM 7X50
GSMP
OSSG298
To support node communication with the access device the line rate, OAM
commands, and so on. the node can use an ANCP string that serves as a key in the
out-of-band channel with the access node. The string can be either provisioned in the
static case, retrieved from RADIUS or from the Python script.
Persistency is available for subscriber’s ANCP attributes and is stored on the on-
board compact flash card. ANCP data stays persistence during an ISSU as well as
nodal reboots. During recovery, ANCP attributes are first restored fully from the
persistence file and incoming ANCP sessions are temporarily on hold. Afterwards
new ANCP data can overwrite any existing values. This new data is then stored into
the compact flash in preparation for the next event.
In the TPSDA framework, nodes fulfill some BRAS functionality, where per
subscriber QoS enforcement is one of the most important aspects. To provide
accurate per-subscriber QoS enforcement, the network element not only knows
about the subscriber profile and its service level agreement but it is aware of the
dynamic characteristics of the subscriber access circuit.
The most important parameters in this context are the subscriber-line capacity (DSL
sync-rate) and the subscriber's channel viewership status (the actual number of BTV
channels received by the given subscriber in any point in time). This information can
be then used to adjust parameters of aggregate scheduling policy.
The DSL forum working documents recommends that a dedicated Layer 2 path (such
as, a VLAN in an Ethernet aggregation network) is used for this communication to
provide a certain level of security. The actual connection between DSLAM and BRAS
is established at TCP level, and then individual messages are transported.
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.
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.
The DHCP ACK response from the DHCP server can be parsed and the contents of
the message can be used to identify the class to which this host belongs, and thus,
the QoS and security settings to apply.
The information necessary to select these settings can be codified in, the IP address
by the DHCP server and/or the Option 82 string inserted by the DSLAM or other
access node.
A tutorial of Python is beyond the scope of this guide but can be found on the Internet
(refer to http://www.python.org/).
Example scripts, using some regular expressions, can be found in Sample Python
Scripts. See the Python Script Support for ESM section for additional information
about the service manager scripting language.
One or more scripts can be written by the operator and stored centrally on a server
(in a location accessible by the router). They are loaded into each router at bootup.
Note that if a centrally stored script is changed, it is not automatically re-loaded onto
the router. The reload must be forced by executing the shutdown and no shutdown
commands on the affected URL(s).
Figure 77 describes the data flow while determining which subscriber profile and SLA
profile to use for a certain subscriber host based on a snooped/relayed DHCP ACK
for that subscriber host.
DHCP
Python Script
ACK
Sub-profile-name Sla-profile-name
Sub-profile Sla-profile-name
• HQOS • Host-limit
• Qos-policies
• Qos-ip-rules
• Ip-filter-rules
OSSG086
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.
Figure 78 shows how the sub-profile is derived, based on the sub-ident string, the
sub-profile string and/or the provisioned data structures. The numbers associated
with the arrows pointing toward the subscriber profiles indicate the precedence of the
checks.
Sla-profile <name>
• Host-limit
• Qos-policies
• Queue params
• Ip-filter
2a
• Qos-ip-rules
• Ip-filter-rules
4
Sub-ident-policy “Name”
Sub-profile “Default”
Sub-profile “ADSL Plus” Sub-profile-map Sla-profile-map
Sub-profile “ADSL Go” sub-profile-string sub-profile-name sla-profile-string sla-profile-name
• Hqos 2b
Sla-profile-map
sla-profile-string sla-profile-name
Script 1 Script 2 Script 3
OSSG087
For each host that comes on-line, the router also needs to determine which SLA
profile to use. The SLA profile determines for this host:
The SLA profile also has host-limits and session-limits attributes that limit the
number of hosts or sessions per SLA profile instance.
The classification and the queue mapping are shared by all the hosts on the same
forwarding complex that use the same QoS policy (by their SLA profile).
The queues/policers are shared by all the hosts (of the same subscriber) on the
same SAP that are using the same SLA profile. In other words, queues/policers are
instantiated when, on a given SAP, a host of a subscriber is the first to use a certain
SLA profile. This instantiation is referred to as an SLA profile instance. Ingress
queues can be parented to a scheduler referenced in the ingress of a subscriber
profile. Egress policers and queues can be parented to a scheduler referenced in the
egress of a subscriber or SLA profile, or to a port scheduler.
A scheduler policy can be applied to the egress an SLA profile, allowing its
schedulers to be the parent for its queues and for its tier 1 schedulers to be parented
to a scheduler in a scheduler policy applied to the egress of a subscriber profile or a
Vport, or to a port scheduler applied to a port or Vport. Configuring scheduler
overrides is allowed for SLA profile egress schedulers. The configuration of a
scheduler policy in the egress of an SLA profile is supported for all host types only
on Ethernet interfaces. It is not supported for ESM over MPLS pseudowires, nor is
HQoS adjustment and host tracking supported on its schedulers.
The following show, monitor and clear commands are available related to the SLA
profile scheduler:
If the SLA profile scheduler is orphaned (that is when the scheduler has a parent
which does not exist) then the hierarchy is only shown when the show command
includes the sla-profile and SAP parameters.
Figure 79 shows a graphical description of how the SLA profile is derived based on
the subscriber identification string, the SLA profile string and the provisioned data
structures. The numbers on the arrows towards the SLA profile indicate the priority
of the provisioning (the lower number means the higher priority).
Sla-profile <names>
• Host-limit
• Qos-policies
• Queue params
• Qos-ip-rules
• Egress scheduler policy 3a
• iIp-filter-rules
Sub-ident-policy “Name”
Sub-profile “Default”
Sub-profile “ADSL Plus” Sub-profile-map Sla-profile-map
Sub-profile “ADSL Go” sub-profile-string sub-profile-name sla-profile-string sla-profile-name
• Hqos 3b
Sla-profile-map
sla-profile-string sla-profile-name
Script 1 Script 2 Script 3
2
al_0371
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.
Each subscriber host or session has an SLA Profile Instance (SPI) associated with
it. The SPI, is by default, determined by the subscriber ID, the SLA profile name, and
the SAP where the subscriber host or session is active. See Figure 74.
SPIs with the same SLA profile name, have the same configuration, however, the
following functions are effective per SPI:
By default, all subscriber sessions or hosts from the same subscriber, active on the
same SAP and with the same SLA profile assigned, share an SPI. The default SPI
sharing is per SAP, as depicted in Figure 80.
Queue 1
PPPoE-2 Queue 2
Queue 3
IPoE-1 Subscriber
scheduler
Bridged RGW
With SPI sharing per SAP, traffic from all subscriber sessions on a given SAP and
with the same SLA profile associated are mapped to the same set of queues and
policers for QoS handling. Statistics from these queues and policers are also used in
accounting. Per-host or per-session accounting modes cannot report counters for
individual sessions unless their traffic is mapped in separate queues.
SPI sharing per SAP is the default configuration in an SLA profile and applies to
PPPoE sessions, IPoE sessions (enabled on the group-interface) and IPoE hosts
(IPoE sessions are disabled on the group-interface):
configure
subscriber-mgmt
sla-profile "sla-profile-1"
def-instance-sharing per-sap
configure
subscriber-mgmt
sla-profile "sla-profile-1"
def-instance-sharing per-session
Per-session sharing applies to PPPoE sessions and IPoE sessions (enabled on the
group interface). An IPoE host setup fails when IPoE sessions are disabled on the
group interface and per-session sharing is configured.
Each IPoE or PPPoE session from the same subscriber, active on the same SAP and
having the same SLA profile assigned, has its own set of queues and policers. Per-
session SPI sharing is depicted in Figure 81.
Queue 1
PPPoE-2 Queue 2
Queue 3
Queue 1
Subscriber
IPoE-1 Queue 2 scheduler
Bridged RGW
Queue 3
Note: SPI sharing per session is not supported on HS MDA and on HSQ with hs-sla-mode
single.
When even more granular control is needed over which sessions share an SPI, an
SPI sharing group identifier can be specified during IPoE or PPPoE session
authentication. This overrides the default SPI sharing method for that session as
configured in the SLA profile.
Per-group SPI sharing is depicted in Figure 82. The same SPI is shared by all IPoE
and PPPoE sessions from the same subscriber, active on the same SAP, having the
same SLA Profile assigned and having the same SPI sharing group identifier.
Note: SPI sharing per group is not supported on HSQ with hs-sla-mode single.
Queue 1
IPoE-1 Queue 2 Subscriber
Queue 3 scheduler
Bridged RGW
The SPI sharing group identifier is an integer value in the range 0 to 65535 and can
be specified in authentication using:
Per-group sharing applies to PPPoE sessions and IPoE sessions (enabled on the
group interface). An IPoE host setup fails when IPoE sessions are disabled on the
group interface and an SPI sharing group identifier is specified.
During the lifetime of an IPoE or PPPoE session, the SLA profile and the SPI sharing
can change. Such a dynamic change can be triggered by re-authentication, RADIUS
CoA, or Diameter Gx RAR by specifying a new SLA profile and optionally, an SPI
sharing group ID.
from
¯ SLA Profile and SPI sharing info provided for dynamic change
to
from
¯ SLA Profile and SPI sharing info provided for dynamic change
to
per group SLA profile = <SLA profile name>
¯ • Optional. Current SLA profile name is used when not specified
per sap • SLA profile with "def-instance-sharing per-sap"
===============================================================================
*A:PE-1# show qos scheduler-hierarchy subscriber "sub-01" detail
===============================================================================
Scheduler Hierarchy - Subscriber sub-01
===============================================================================
--- snip ---
Root (Egr)
| slot(1)
|--(Q) : Sub=sub-01:sla-profile-12 1000->1/1/4:1201.41->6 (Port 1/1/4)
| | AdminPIR:1500 AdminCIR:1500
--- snip ---
Note: Although they can have the same value as in the following output, an SPI sharing id
is not the same as the PPP session id.
---snip---
Root (Egr)
| slot(1)
|--(Q) : Sub=sub-01:sla-profile-12:Group-100 1000->1/1/4:1201.41->6 (Port 1/1/4)
| | AdminPIR:1500 AdminCIR:1500
---snip---
configure
subscriber-mgmt
radius-accounting-policy "acct-policy-1"
include-radius-attribute
subscriber-id
nas-port-id
sla-profile
spi-sharing
For example:
The egress QoS marking for subscriber-host traffic is derived from the SAP-egress
QoS policy associated with a corresponding SAP, rather than from the SLA profile
associated with the corresponding subscriber host. Therefore, no egress QoS
marking (Dot1p marking is set to 0, the dscp/prec field is kept unchanged) is
performed for traffic transmitted on a managed SAP because by default, sap-egress
policy 1 is attached to every managed SAP.
The default value of the “qos-marking-from-sap” flag is enabled. This means that the
qos-marking defined in the SAP egress QoS policy associated with the SAP is used.
The default setting of this flag in a combination with managed-SAP results in the
same behavior as in the current system (dot1p=0, dscp/prec is unchanged).
Changing the flag setting in the SLA profile being used by any subscriber-hosts (this
includes subscriber-hosts on managed-SAPs as well) is allowed.
As a result of this length increase, all MIB tables containing sub-id and brg-id names
are affected. In a majority of those tables, the sub-id and brg-id name length is
directly increased from 32 characters to 64 characters. However, tables where the
MIB OID key contains a sub-id or brg-id as one of the fields do not increase the size
of the sub-id and brg-id fields since the maximum key size of 128 characters could
be exceeded when the sub-id and brg-id names are combined to form the key. Since
the maximum size of the key in the MIB tables is limited to 128 characters, the sub-
id and brg-id length in such tables remains limited to 32 characters. This ensures that
the MIB key does not exceed the maximum size of 128 characters. This also means
that an operator-defined sub-id and brg-id name that is greater than 32 characters
must be internally translated (within the SR OS) into a 32-character identification.
Rather than truncating sub-id and brg-id names that are greater than 32 characters
to a 32 characters value (which could lead to duplicate sub-ids or brg-ids), an internal
and unique 32-character length sub-id and brg-id is automatically generated by the
system. These internally generated sub-id and brg-id names are used in the following
tables where the long sub-id and brg-id (>32characters) could lead to violations of
the maximum key size (128 characters). The affected tables are:
• TIMETRA-SUBSCRIBER-MGMT-MIB:
- tmnxSLAProfInstOverridesEntry
- tmnxSubSpiOvrEntry
- tmnxSLAProfInstSubHostV2Entry
- tmnxSubSpiHostEntry
- tmnxSPICatEntry
- tmnxSubSpiCatEntry
- tmnxSpiEgrQosSchedStatsEntry
- tmnxSPIEgrQosSchedStatsEntry
• TIMETRA-NAT-MIB:
- tmnxNatL2AwHostPlcyEntry
- tmnxNatFwlHostEntry
- tmnxNatFwd2Entry
The operator-defined long sub-id and long brg-id names are listed in these tables and
replaced with the internally-generated version with a 32-character length version.
Table 18 shows examples of sub-id and brg-id names where a long sub-id and long
brg-id may lead to a violation of the maximum key size. The internally-generated ID
begins with the _tmnx_ prefix:
The operator-defined sub-ids and brg-ids with lengths up to 32 characters are not
affected by this change.
In most cases, operators are not concerned with the internal sub-id and brg-id which
are only used by the system to access data in one of the 11 MIB tables where the
long sub-id or long brg-id would otherwise violate the maximum length of the key.
Therefore, the internal ID is not shown in the output of any show command.
An exception occurs when a SNMP table walk is performed in one of the 11 tables
in which an entry of interest is found that contains an internal sub-id and brg-id, that
needs to be connected with the real (long) subscriber identity.
Table 19 tmnxSubShortEntry
tmnxSubShortId tmnxSubLongId
ABCshort ABCshort
_tmnx_sub_123 defLongstring
_tmnx_sub_456 JKLLongstring
ghiShort ghiShort
Table 20 tmnxSubBrgShortEntry
tmnxSubBrgShortId tmnxSubBrgLongId
MNPshort ABCshort
_tmnx_brg_333 xyzLongstring
_tmnx_brg_222 OQRLongstring
WVZShort WVZhort
Table 21 tmnxSubscriberInfoEntry
Table 22 tmnxSubBrgEntry
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.
• 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
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 multi-homing 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 multi-homing, if they are
needed by the operator, they must be re-retrieved after a chassis reboot even
when persistency is enabled.
9.3.9 Auto-Sub ID
The subscriber ID name (sub-id) is a mandatory object that binds all hosts of a given
subscriber together. Briefly, the sub-id name represents a residential household.
Many management/troubleshooting and even billing operations rely on the sub-id
name entity. The sub-id name is required for the host creation process, and it can be
supplied by any authentication source, such as RADIUS, Diameter, LUDB, or
Python. It can be derived from the sap-id or can be statically provisioned in the form
of a string.
• RADIUS server provides the SLA profile string and the sub-profile string but not
the sub-id string.
There can be only a single set of subscriber identification fields defined per host type
(IPoE or PPPoE) per chassis. If the combination of the fields must be modified, the
existing subscribers with an automatically generated subscriber ID must be manually
terminated. Considering that remote termination of the IPoE subscribers by a DHCP
server is not supported by all DHCP client vendors through the FORCERENEW
DHCP message (RFC 3203, DHCP reconfigure extension), changing the subscriber
fields while subscribers with automatically generated subscriber ID are active should
be avoided.
The subscriber ID name automatic generation takes place at the end of the host
initiation process (after the authentication phase is completed) and only in case
whereby the subscriber ID had not been already provided by any other more specific
means (RADIUS, Diameter, LUDB, or Python).
The format of the sub-id name can be either a 10-character encoded string
(characters A to Z and 0 to 9) or a user- friendly string based on the subscriber
identification fields. The maximum length of the subscriber ID name is 64 characters.
The subscriber ID name is not passed in the Access-Request to the RADIUS server
since it is generated after the authentication phase.
The subscriber ID name can be automatically generated regardless of how the SLA
or subscriber profile strings are obtained (RADIUS, LUDB, Python, or static).
configure
subscriber-mgmt
auto-sub-id-key
ppp-sub-id-key [mac] [sap-id] [circuit-id] [remote-
id] [session-id]
The order in which the fields are configured is important because the subscriber ID
name potentially becomes a concatenated string of the subscriber host identifiers in
the order in which they are provisioned. The subscriber ID cannot be longer than 64
characters.
• If the length of the concatenated fields for the subscriber ID name is longer than
64 characters, the host creation fails.
• If the circuit ID or remote ID is in the key and they contain non-printable
characters, their place in subscriber ID name are formatted in hex instead of
ASCII. ASCII printable characters can contain the byte values 0x20 to 0x7E. All
other values are ASCII non-printable and thus, are formatted in hex characters.
• mac: xx:xx:xx:xx:xx:xx
• sap: 1/1/3:23
• session-id: 44 (16bits length)
If the key contains the circuit ID as: 0x610163 (3 bytes), then the subscriber ID name
is formatted as 610161, in hex, since 01 hex is non-printable in ASCII. Then the
subscriber ID name’s length is 6B.
However, if the circuit ID is 0x616263 (3 bytes), then the string is formatted as ASCII
string abc (three characters). The subscriber ID name’s length is 3B.
A subscriber ID name obtained from authentication sources can conflict with the
format of an implicit auto-generated subscriber ID name. When this happens,
the subscriber host or session setup fails. Therefore, when implicit subscriber ID
name generation is enabled (the default), a 10-character string containing the
characters A to Z and 0 to 9 should not be returned from authentication sources.
Information in Step 3 describes information to disable the implicit automatic
generation of a subscriber ID name.
2. An explicit configured default is configured as def-sub-id:
- At the SAP level for static SAPs:
configure
service ies/vprn
subscriber-interface <ip-int-name>
group-interface <ip-int-name>
sap <sap-id>
sub-sla-mgmt
def-sub-id use-sap-id | use-auto-id | string <sub-id>
where:
- use-sap-id: the sub-id name is the SAP identifier
- use-auto-id: the sub-id name is a combination of the identifiers specified in
auto-sub-id-key.
The sub-id name is in a readable format, that is, a concatenation of the
fields in the pppoe-sub-id-key or ipoe-sub-id-key command separated by
a “|” character.
- string: the sub-id name is a user defined string
3. Implicitly generated default:
When no subscriber ID name is provided in authentication, and no explicit
default is configured, then the system, by default, automatically generates a
subscriber ID name, a 10-character string, using characters A to Z and 0 to 9,
that is based on the fields defined in the:
- ppp-sub-id-key command for PPP host types. If no such fields are explicitly
defined, the default are assumed: mac, sap-id, session-id.
- ipoe-sub-id-key command for IPoE host types. If no such fields are
explicitly defined, the defaults are assumed: mac, sap-id.
The implicitly generated subscriber ID name is unique per chassis as well as in
dual-homed environments.
The implicit automatic subscriber ID name generation can be disabled with the
following command: configure subscr-mgmt auto-sub-id-key no implicit-
generation.
- The implicit auto-sub-id name generation cannot be disabled when there
are active subscribers in the system with an implicit automatically generated
subscriber ID name.
- When disabled, the implicit auto-sub-id name generation cannot be enabled
when there are active subscribers in the system.
With implicit subscriber ID generation disabled, the subscriber host or session
setup fails when no subscriber ID name is provided in authentication, and no
explicit default is configured. A 10-character subscriber ID name format, using
the characters A to Z and 0 to 9, can be returned from authentication sources
without risk of conflict.
• 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.
Regardless of which host comes up first, those two hosts at the end belong to
different subscribers if their sub-ids are different.
config
subscriber-mgmt
auto-sub-id-key
ppp-sub-id-key sap-id
ipoe-sub-id-key mac circuit-id
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>
In the first case where RADIUS returns the sub-id string, the following occurs
• 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.
9.3.9.5 Caveats
Only a single combination of the subscriber fields used to auto generate sub-id is
allowed per host type (IPoE or PPPoE) and per chassis. In case that the combination
of the fields needs to be changed, the existing subscribers with an auto-generated
sub-id must be manually terminated. Considering that remote termination of the IPoE
subscribers by DHCP server is not supported by all DHCP client vendors through
FORCERENEW DHCP message (RFC 3203), changing the subscriber fields while
subscribers with auto generated sub-id are active should be avoided.
The setup of a new subscriber host or session fails if any of these limits is reached.
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.
9.3.10.3 Limiting the Number of Hosts and Sessions per SLA Profile
Instance and per Subscriber
Table 23 list the host limits and Table 25 lists the session limits that can be
configured in the following profiles:
Example
For a bridged RGW, allow one dual stack IPoE session (IPv4 and IPv6 IA-PD) per
SLA profile instance and up to two sessions per subscriber.
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
Table 24 specifies the host-limits counters that are applicable for each of the different
subscriber host types in SR OS. Table 26 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.
Note: If the remove-oldest command is configured in the host-limits context and an IPv4
ARP host, IPv4 DHCP host, IPv4 host, or subscriber host limit is reached when a new
DHCPv4 host or an ARP host connects, the oldest active host disconnects and the new host
is granted access. The dynamic host with the least remaining lease time is considered the
oldest host. The remove-oldest command is not applicable for PPPoE or IPv6 subscriber
hosts.
ipv6-pd-overall Limits the total number of IPv6 DHCP Prefix Delegation hosts (IA-PD)
ipv6-pd-ipoe-dhcp Limits the number of IPv6 IPoE DHCP Prefix Delegation hosts (IA-PD)
ipv6-wan-ipoe-dhcp Limits the number of IPv6 IPoE DHCP WAN hosts (IA-NA)
ipv6-wan-ppp-dhcp Limits the number of IPv6 PPPoE DHCP WAN hosts (IA-NA).
Table 24 Host Limit Counters Applicable per Subscriber Host Type (Continued)
The host and session limits per SLA profile instance and per subscriber can be
overridden at subscriber host or session creation by the following.
The combination of overrides and configured limits is only checked when the host or
session is created.
Overrides are stored in the subscriber host and session ESM info and can be
displayed using the following show commands:
For example:
# 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
Note: If different subscriber hosts or sessions that belong to the same SLA profile instance
or subscriber have different override limits, an inconsistent behavior can occur when
sessions are recovered from persistency or in case of Multi-Chassis Synchronization
(MCS). This may occur because the order in which hosts recover from persistency and the
order in which the hosts or sessions are synchronized through MCS, may be different from
the order in which sessions were created in the system.
Since a subscriber identification policy is not applicable to static subscriber hosts, the
subscriber identification string, subscriber profile and SLA profile must be explicitly
defined with the host’s IP address and MAC address (if Enhanced Subscriber
Management is enabled).
If an SPI associated with the named SLA profile already exists on the SAP for the
subscriber, the static subscriber host is placed into that SPI. If an SPI does not yet
exist, one is created if possible. If the SLA profile cannot be created, or the host
cannot be placed in the existing SPI (the host-limits was exceeded), the static host
definition fails.
QoS aspects for subscribers and hosts can be defined statically on a SAP or
dynamically using.
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.
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 ingress hierarchical parenting relationship options are shown in Figure 83.
Queue
Queue T1 T2 T3
al_0372
The egress hierarchical parenting relationship options are shown in Figure 84. 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.
parent-location default
T1 T2 T3 queue/policer
port-parent
queue/policer
port-parent
queue/policer
parent-location parent-location
sub sla
T1 T2 T3 T1 T2 T3 queue
parent-location parent-location
port-parent sub sla
T1 T2 T3 T1 T2 T3 queue
parent-location parent-location
port-parent sub sla
T1 T2 T3 T1 T2 T3 queue
parent-location
port-parent sla
T1 T2 T3 queue
parent-location
port-parent parent-location vport sla
T1 T2 T3 T1 T2 T3 queue
parent-location
port-parent sla
T1 T2 T3 queue
No3493
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.
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).
A tier 1 scheduler in the scheduler policy applied to the egress of an SLA profile can
parent to a scheduler applied to the egress of a subscriber profile.
A tier 1 scheduler in the scheduler policy applied to the egress of a subscriber profile
can parent to a scheduler applied to the egress of a Vport.
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.
Note: Ingress policed traffic uses the shared policer-output-queues to access the switch
fabric. At egress, the policed traffic accesses the egress port through a queue group queue
(by default the policer-output-queues queue group, though user configurable queue groups
can also be used) or a locally configured subscriber queue.
The ingress hierarchical parenting relationship options are shown in Figure 85.
Policer
Policer R A1 A2
Ingress Shared
Policer-output-
SAP Ingress QoS Policy Policer Control Policy queues to Access
the Switch Fabric
al_0374
The egress hierarchical parenting relationship options are shown in Figure 86.
Policer
R A1 A2 Policer
Egress Policer-output-queues
or User Configured Queue-
group, or Local Queue to Policer Control Policy SAP Egress QoS Policy
Access the Port
al_0375
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) due to the last mile for each type of broadband session,
that is, PPPoEoA LLC/SNAP and VC-Mux, IPoE, IPoEoA LLC/SNAP and VC-Mux,
and so on, is accounted for by the 7450 ESS and 7750 SR acting as the Broadband
Network Gateway (BNG).
The intent is that the BNG distributes bandwidth among the subscriber host sessions
fairly by accounting for the encapsulation overhead and bandwidth expansion of the
last mile so the packets are less likely to be dropped downstream in the DSLAM DSL
port.
The last mile encapsulation type can be configured by the user or signaled using the
Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoE Tags or DHCP
Relay Options as per RFC 4679.
Furthermore, this feature allows the BNG to shape the aggregate rate of each
subscriber and the aggregate rate of all subscribers destined to a given DSLAM to
prevent congestion of the DSLAM. The subscriber aggregate rate is adjusted for the
last mile overhead. The shaping to the aggregate rate of all subscribers of a given
destination DSLAM is achieved by a new scheduling object, referred to as Virtual
Port or Vport in CLI, which represents the DSLAM aggregation node in the BNG
scheduling hierarchy
Subscriber
Management
7750 BNG
BSAN Broadband Network
Broadband Service Gateway
RG
Residential Access Node
IP-MPLS
Gateway Core
Ethernet Subscriber
Backhaul Management
DHCP RADIUS
EG
Enterprise
Gateway
al_0026
Residential and business subscribers use PPPoEoA, PPoA, IPoA, or IPoEoA based
session over ATM/DSL lines. Each subscriber host can use a different type of
session. Although Figure 87 illustrates ATM/DSL as the subscriber last mile, this
feature supports both ATM and Ethernet in the last mile.
When the 7750 BNG forwards IP packets from the IP-MPLS core network
downstream towards the Residential Gateway (RG) or the Enterprise Gateway (EG),
it adds the required PPP and Ethernet headers, including the SAP encapsulation with
C-VLAN/S-VLAN. When the BSAN node receives the packet, it strips the S-VLAN
tag, strips or overwrites the C-VLAN tag, and adds padding to minimum Ethernet size
if required. It also adds the LLC/SNAP or VC-mux headers plus the fixed AAL5 trailer
and variable AAL5 padding (to next multiple of 48 bytes) and then segments the
resulting PDU into ATM cells when the last mile is ATM/DSL. Thus the packet size
undergoes a fixed offset due to the encapsulation change and a variable expansion
due to the AAL5 padding when applicable. Each type of subscriber host session
requires a different amount of fixed offset and may require a per-packet variable
expansion depending on the encapsulation used by the session. The BNG node
learns the encapsulation type of each subscriber host session by inspecting the
Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoE Tags as
specified in RFC 4679. The BNG node must account for this overhead when shaping
packets destined to subscriber.
Figure 88 illustrates the queuing and scheduling model for a BNG using the Ethernet
or ATM last-mile aware QoS feature.
C-VLAN1 Residential
Virtual Port for S-VLAN=20 Subscriber agg-rate-limit
(Provides Destination
agg-rate Support) Residential Weight X
BE Q 1
W1 Weight Y
L2 Q 2
Prio=3 Weight Z
L1 Q 3
Business H2 Q 4
Prio=4
W4 H1 Q 5
Prio=4 EF Q 6
Uncontended
port Weight X
Vport
BE Q 1
Max-rate Prio=5 Weight Y
(S-VLAN=20 Rate) L2 Q 2
Weight Z
L1 Q 3
Prio=7 H2 Q 4
H1 Q 5
EF Q 6
Prio=8
C-VLAN2 Business
Subscriber agg-rate-limit
al_0027
A set of per FC queues are applied to each subscriber host context to enforce the
packet rate within each FC in the host session as specified in the subscriber’s host
SLA profile. A packet is stored in the queue corresponding the packet’s FC as per
the mapping of forwarding class to queue-id defined in the sap-egress QoS policy
used by the host SLA profile. In the BNG application however, the host per FC queue
packet rate is overridden by the rate provided in the RADIUS access-accept
message. This rate represents the ATM rate that is seen on the last mile, that is, it
includes the encapsulation offset and the per packet expansion due to ATM
segmentation into cells at the BSAN.
To enforce the aggregate rate of each destination BSAN, a scheduling node, referred
to as virtual port, and Vport is in the CLI. The Vport operates exactly like a port
scheduler with the difference that multiple Vport objects can be configured on the
egress context of an Ethernet port. The user adds a Vport to an Ethernet port using
the following command:
The Vport is always configured at the port level even when a port is a member of a
LAG. The vport-name is local to the port it is applied to but must be the same for all
member ports of a LAG. It however does not need to be unique globally on a chassis.
The user applies a port scheduler policy to a Vport using the following command:
A Vport cannot be parented to the port scheduler when it is using a port scheduler
policy itself. It is thus important the user ensures that the sum of the max-rate
parameter value in the port scheduler policies of all Vport instances on a given
egress Ethernet port does not oversubscribe the port’s hardware rate. If it does, the
scheduling behavior degenerates to that of the H/W scheduler on that port. A Vport
which uses an agg-rate can be parented to a port scheduler. This is explained in
Applying Aggregate Rate Limit to a Vport. Note that the application of the agg-rate,
port-scheduler-policy and scheduler-policy commands under a Vport
configuration are mutually exclusive.
Each subscriber host queue is port parented to the Vport which corresponds to the
destination BSAN using the existing port-parent command:
This command can parent the queue to either a port or to a Vport. These operations
are mutually exclusive in CLI as explained above. When parenting to a Vport, the
parent Vport for a subscriber host queue is not explicitly indicated in the above
command. It is determined indirectly. The determination of the parent Vport for a
given subscriber host queue is described in Vport Determination and Evaluation.
The aggregate rate of each subscriber must also be enforced. The user achieves this
by applying the existing agg-rate-limit command to the egress context of the
subscriber profile:
In the BNG application however, this rate is overridden by the rate provided in the
RADIUS access-accept message. This rate represents the ATM rate that is seen on
the last mile, that is, it includes the encapsulation offset and the per packet expansion
due to ATM segmentation into cells at the BSAN.
The existing port scheduler policy defines a set of eight priority levels with no ability
of grouping levels within a single priority. To allow for the application of a scheduling
weight to groups of subscriber host queues competing at the same priority level of
the port scheduler policy applied to the Vport, or to the Ethernet port, a new group
object is defined under the port scheduler policy:
Up to eight groups can be defined within each port scheduler policy. One or more
levels can map to the same group. A group has a rate and optionally a cir-rate and
inherits the highest scheduling priority of its member levels. For example, the
scheduler group shown in the Vport consists of level priority 3 and level priority 4. It
thus inherits priority 4 when competing for bandwidth with the standalone priority
levels 8, 7, and 5.
In essence, a group receives bandwidth from the port or from the Vport and
distributes it within the member levels of the group according to the weight of each
level within the group. Each priority level competes for bandwidth within the group
based on its weight under congestion situation. If there is no congestion, a priority
level can achieve up to its rate (cir-rate) worth of bandwidth.
Note: CLI enforces that mapping of levels to a group are contiguous. In other words, a user
would not be able to add priority level to group unless the resulting set of priority levels is
contiguous.
When a level is not explicitly mapped to any group, it maps directly to the root of the
port scheduler at its own priority like in existing behavior.
Software-Based Implementation
The subscriber aggregate rate is adjusted and based on an average frame size.
The user enables the use of this adjustment method by configuring the following
option in the egress context of the subscriber profile:
This command allows the user to configure a default value to be used by all hosts of
the subscriber in the absence of a valid signaled value. The following is a list of the
configurable values:
Otherwise, the fixed packet offset is derived from the encapsulation type value
signaled in the Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoE
Tags as explained in Section Signaling of Last Mile Encapsulation Type. Only
signaling using PPPoE Tags is supported in the software based implementation. The
last signaled valid value is then applied to all active hosts of this subscriber. If no
value is signaled in the subscriber host session or the value in the fields of the
Access-loop-encapsulation sub-TLV are invalid, then the offset applied to the
aggregate rate of this subscriber uses the last valid value signaled by a host of this
subscriber if it exists, or the user entered default type value if configured, or no offset
is applied.
Configure the average frame size value to be used for this adjustment:
The entered value must include the FCS but not the Inter-Frame Gap (IFG) or the
preamble. If the user does not explicitly configure a value for the avg-frame-size
parameter, then it is also assumed the offset is zero regardless of the signaled or
user-configured value.
The computation of the subscriber aggregate rate consists of taking the average
frame size, adding the encapsulation fixed offset including the AAL5 trailer, and then
adding the variable offset consisting of the AAL5 padding to next multiple of 48 bytes.
The AverageFrameExpansionRatio is then derived as follows:
The following are the frame size and rate applied to the subscriber queue and
scheduler:
sub-oper-agg-rate = min(sub-policy-agg-rate/AverageFrameExpansionRatio,
ancp_rate/AverageFrameExpansionRatio) + (igmp_rate_delta/
AverageFrameExpansionRatio),
The following are the procedures for handling signaling changes or configuration
changes affecting the subscriber profile:
1. If a new RADIUS update comes in for the aggregate subscriber rate, then a new
subscriber aggregate ATM adjusted rate is computed by CPM using the last
configured avg-frame-size and then programmed to IOM.
2. If the user changes the value of the avg-frame-size parameter, enables/
disables the encap-offset option, or changes the parameter value of the encap-
offset option, the CPM immediately triggers a re-evaluation of subscribers using
the corresponding subscriber profile and an update the IOM with the new
subscriber aggregate rate.
3. If the user changes the value of the agg-rate-limit parameter in a subscriber
profile which has the avg-frame-size configured, this immediately triggers a re-
evaluation of subscribers using the corresponding subscriber profile. An update
to the subscriber aggregate rate is performed for those subscribers which rate
has not been previously overridden by RADIUS.
4. If the user changes the type value of the encap-offset command, this
immediately triggers a re-evaluation of subscribers using the corresponding
subscriber profile. An update to the subscriber aggregate rate is performed for
those subscribers which are currently using the default value.
5. If two hosts of the same subscriber signal two different encapsulation types, the
last one signaled gets used at the next opportunity to re-evaluate the subscriber
profile.
6. If a subscriber has a DHCP host, a static host or an ARP host, the subscriber
aggregate rate continues to use the user-configured default encapsulation type
value or the last valid encapsulation value signaled in the PPPoE tags by other
hosts of the same subscriber. If none was signaled or configured, then no rate
adjustment is applied.
Like in the software based implementation, the user enables the use of the fixed
offset and per packet variable expansion by configuring the following option in the
egress context of the subscriber profile:
When this command is enabled, the fixed packet offset is derived from the
encapsulation type value signaled in the Access-loop-encapsulation sub-TLV in the
Vendor-Specific PPPoE Tags or DHCP Relay Options as explained in Section
Signaling of Last Mile Encapsulation Type.
If the user specifies an encapsulation type with the command, this value is used as
the default value for all hosts of this subscriber until a host session signaled a valid
value. The signaled value is applied to this host only and the remaining hosts of this
subscriber continue to use the user entered default type value if configured, or no
offset is applied. Hosts of the same subscriber using the same SLA profile and which
are on the same SAP share the same instance of FC queues. In this case, the last
valid encapsulation value signaled by a host of that same instance of the SAP egress
QoS policy overrides any previous signaled or configured value.
2. If the user specifies an encapsulation type with the command, this value is used
as the default value for all hosts of this subscriber until a host session signaled
a valid value. The signaled value is applied to this host and other hosts of the
same subscriber sharing the same SLA profile and which are on the same SAP.
The remaining hosts of this subscriber continue to use the user entered default
type value if configured, or no offset is applied.
3. If the user enables/disables the encap-offset option, or changes the parameter
value of the encap-offset option, the CPM immediately triggers a re-evaluation
of subscriber hosts using the corresponding subscriber profile and an update the
IOM with the new fixed offset value.
4. If subscriber host session signals an encapsulation type at the session
establishment time and subsequently sends a DHCP renewal message using a
Layer 2 DHCP relay which does not insert option82 in a unicast message, the
encapsulation type for this host does not change. TR-101 states that option82 is
mandatory for DHCP broadcast messages).
5. If a subscriber has a static host or an ARP host, the subscriber host continues
to use the user-configured default encapsulation type value or the last valid
encapsulation value signaled in the PPPoE tags or DHCP relay options by other
hosts of the same subscriber which use the same SLA profile instance. If none
was signaled or configured, then no rate adjustment is applied.
6. The encapsulation type value signaled in DHCP relay options or PPPoE tags are
not cross-checked against the host type. Thus, a host signaling PPPoA/LLC
encapsulation type through DHCP relay options are not handled as if the packet
included a PPPoE header when forwarded over the local Ethernet port. This
results in applying an encap-offset in the data path which assumes the PPPoE
header is added to forwarded packets over the local Ethernet port.
The encap-offset option forces all the rates to be either last-mile frame over the wire
or local port frame over the wire, referred to as LM-FoW and FoW respectively. The
system maintains a running average frame expansion ratio for each queue to convert
queue rates between these two formats as explained in Frame Size, Rates, and
Running Average Frame Expansion Ratio. The following are details of the queue and
scheduler operation:
9.3.13.3.5 Frame Size, Rates, and Running Average Frame Expansion Ratio
The following are the details of the rates and frame sizes applied to the subscriber
host queues, the subscriber aggregate rate, and the Vport root scheduler for the
scheduling model and when the encap-offset option is enabled in the subscriber
profile.
This size is then adjusted by removing the ImmediateEgressEncap and adding the
LastMileFrameOverWireEncap. This new adjusted frame size, referred as
LastMileOfferedFrameSize, is then used for checking compliance of the frame
against the queue PIR and CIR bucket sizes and for updating the queue forwarded
and dropped stats.
The vport/port port-scheduler hands out its FoW bandwidth in terms of Fair
Information Rate (FIR) bandwidth to each subscriber queue. This queue FIR must be
converted into LM-FoW format to cap it by the queue PIR (adminPIR) and to make
sure the sum of FIRs of all queues of the same subscriber does not exceed the
subscriber agg-rate-limit which is also expressed in LM-FoW format. The
conversion between these two rates makes use of the cumulative
RunningAverageFrameExpansionRatio value.
A queue LM-FoW AdminPIR value is always capped to the value of the local port
FoW rate even if the conversion based on the current
RunningAverageFrameExpansionRatio value indicates that a higher AdminPIR may
be able to fill in the full line rate of the local port.
In the BNG application, host queues of all subscribers destined to the same
downstream BSAN, for example, all SAPs on the egress port matching the same S-
VLAN tag value, are parented to the same Vport which matches the destination ID of
the BSAN.
The BNG determines the parent Vport of a subscriber host queue, which has the
port-parent option enabled, by matching the destination string associated with the
subscriber with the string defined under a Vport on the port associated with the
subscriber.
The user configures the dest string match under the egress Vport context of the
Ethernet port associated with the subscriber:
If a given subscriber host queue does not have the port-parent option enabled, it is
foster-parented to the Vport used by this subscriber and which is based on matching
the dest string. If the subscriber could not be matched with a Vport on the egress
port, the host queue is not bandwidth controlled and competes for bandwidth directly
based on its own PIR and CIR parameters.
By default, a subscriber host queue with the port-parent option enabled is scheduled
within the context of the port’s port scheduler policy. To indicate the option to
schedule the queue in the context of a port scheduler policy associated with a Vport,
the user enters the following command in SLA profile used by the subscriber host:
This command is persistent meaning that the user can re-enter the qos node without
specifying the vport-scheduler argument each time and the system remembers it.
The user can revert to the default setting without deleting the association of the SLA
profile with the SAP egress QoS policy by explicitly re-entering the command with the
following new argument:
The user can apply an aggregate rate limit to the Vport and apply a port scheduler
policy to the port.
This model allows the user to oversubscribe the Ethernet port. The application of the
agg-rate option is mutually exclusive with the application of a port scheduler policy,
or a scheduler policy to a Vport.
When using this model, a subscriber host queue with the port-parent option enabled
is scheduled within the context of the port’s port scheduler policy. However, the user
must still indicate to the system that the queues are managed by the aggregate rate
limit instance of a Vport by enabling the vport-scheduler option in the subscriber
host SLA profile:
If a given subscriber host queue does not have the port-parent option enabled, it is
foster-parented to the port used by this subscriber and aggregate rate limited within
the instance of the Vport used by this subscriber. If the Vport exists but the port does
not have a port scheduler policy applied, then the host queue is orphaned and no
aggregate rate limit can be enforced.
The user can apply a scheduler policy to the Vport. This allows scheduling control of
subscriber tier 1 schedulers in a scheduler policy applied to the egress of a
subscriber or SLA profile, or to a PW SAP in an IES or VPRN service.
The advantage of using a scheduler policy under a Vport, compared to the use of a
port scheduler (with or without an agg-rate), is that it allows a port parent to be
configured at the Vport level.
The configuration of a scheduler policy under a Vport is mutually exclusive with the
configuration of a port scheduler policy or an aggregate rate limit.
If the Vport exists, but port does not have a scheduler policy applied, then its
schedulers are orphaned and no port level QOS control can be enforced.
show qos scheduler-stats port port-id vport name [scheduler scheduler-name] [detail]
monitor qos scheduler-stats port port-id vport name [interval seconds ] [repeat
repeat] [absolute | rate]
HQoS adjustment and host tracking are not supported on schedulers that are
configured in a scheduler policy on a Vport, so the configuration of a scheduler policy
under a Vport is mutually exclusive with the configuration of the egress-rate-modify
parameter.
ESM over MPLS pseudowires are not supported when a scheduler policy is
configured on a Vport.
A subscriber host session can signal one of many encapsulation types each with a
different fixed offset in the last mile. These encapsulation types are described in RFC
4679 and are illustrated in Figure 89 and Figure 90. The BNG node learns the
encapsulation type of each subscriber host session by inspecting the Access-loop-
encapsulation sub-TLV in the Vendor-Specific PPPoE Tags as specified in RFC
4679.When Ethernet is the last mile, the encapsulation type results in a fixed offset
for all packet sizes. When ATM/DSL is the last mile, there is an additional expansion
due to AAL5 padding to next multiple of 48 bytes and which varies depending on the
packet size.
The software and hardware based implementations support both ATM and Ethernet
access using PPP encapsulation options. Thus, both provide support for the Access-
loop-encapsulation sub-TLV in the Vendor-Specific PPPoEv4/PPPoEv6 Tags with
the ATM encapsulation values and Ethernet encapsulation values. ATM and
Ethernet access using IP encapsulation are only supported using default
encapsulation offset configuration in the subscriber profile in the software based
implementation. Support for signaling the Access-loop-encapsulation sub-TLV in the
DHCPv4/DHCPv6 Relay Options is included in the hardware based implementation.
There is no support for DHCPv6 relay options.
Bridged IPoA IP
Routed IPoA PPPoA (RFC 2684) PP = 0x0021 2
(RFC 2684) (RFC 2364) IP PPPoE 6
IP IP Ethernet: Type = 0800 (IP) Ethernet: Type = 8864 14/18
PPP = 0x0021 SNAP: Control=0x0080C2 SNAP: Control=0x0080C2
SNAP: Control=0x000000 5
Type=0x0800 (IP) NLPID = OxCF (PPP) Type=0x0001/0x0007 Type=0x0001/0x0007
Access-loop-encapsulation
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Link | Encaps 1 | Encaps 2 | Encapsulation combinations
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The operational last-mile values for hosts on the same SAP, having the same SLA
profile are displayed in following the show command:
The data-link can have values: atm, other and, unknown. If no offset is supplied it
is set to unknown. other is used when the data-link is non-atm, otherwise it states
atm.
Root (Egr)
| slot(1)
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->8->ATM (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->7->ATM (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->6->ATM (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->5->ATM (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->4->ATM (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->3->ATM (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->2->ATM (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->1->ATM (Port 1/1/11)
|
Root (Egr)
| slot(1)
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->8->Eth (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->7->Eth (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->6->Eth (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->5->Eth (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->4->Eth (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->3->Eth (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->2->Eth (Port 1/1/11)
|
|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->1->Eth (Port 1/1/11)
|
The following CLI configuration achieves the specific use case shown in Figure 88.
config
qos
port-scheduler-policy "dslam-vport-scheduler"
group res-bus-be create
rate 1000
level 3 rate 1000 group res-bus-be weight w1
level 4 rate 1000 group res-bus-be weight w4
level 5 rate 1000 cir-rate 100
level 7 rate 5000 cir-rate 5000
level 8 rate 500 cir-rate 500
max-rate 5000
port-parent level 5
queue 5 // h1-res
port-parent level 7
queue 6 // ef-res
port-parent level 8
fc be queue 1
fc l2 queue 2
fc l1 queue 3
fc h2 queue 4
fc h1 queue 5
fc ef queue 6
exit
sap-egress 200 // business policy
queue 1 // be-bus
port-parent weight x level 4
queue 2 // l2-bus
port-parent weight y level 4
queue 3 // l1-bus
port-parent weight z level 4
queue 4 // h2-bus
port-parent level 5
queue 5 // h1-bus
port-parent level 7
queue 6 // ef-bus
port-parent level 8
fc be queue 1
fc l2 queue 2
fc l1 queue 3
fc h2 queue 4
fc h1 queue 5
fc ef queue 6
exit
exit
config
sub-mgmt
sla-profile "residential"
egress
qos 100 vport-scheduler
exit
exit
sla-profile "business"
egress
qos 200 vport-scheduler
exit
exit
sub-profile "residential"
egress
encap-offset
avg-frame-size 1500
agg-rate-limit 100
exit
exit
exit
sub-profile "business"
egress
encap-offset type pppoeoa-llc-tagged-fcs
avg-frame-size 500
agg-rate-limit 200
exit
exit
exit
exit
config
port 1/1/1
ethernet
access
egress
vport "dslam-1" create
port-scheduler-policy "dslam-vport-scheduler"
host-match dest “20” create
exit
exit
exit
exit
exit
exit
exit
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
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 details on sap-ingress
and sap-egress policer stat-mode, refer to the 7450 ESS, 7750 SR, 7950 XRS, and
VSR Quality of Service Guide. For a policer in stat-mode v4-v6, following counters
are available:
When a policer’s stat-mode is changed while the SLA profile is in use, any previous
counter values are lost and any new counters are set to zero.
• 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
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
------------------------------------------------------------------------
SLA Profile Instance per Queue statistics
------------------------------------------------------------------------
Packets Octets
------------------------------------------------------------------------
SLA Profile Instance per Policer statistics
------------------------------------------------------------------------
Packets Octets
• 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):
[26-6527-194] Alc-IPv6-Acct-Input-Packets
[26-6527-195] Alc-IPv6-Acct-Input-Octets
[26-6527-196] Alc-IPv6-Acct-Input-GigaWords
[26-6527-197] Alc-IPv6-Acct-Output-Packets
[26-6527-198] Alc-IPv6-Acct-Output-Octets
[26-6527-199] Alc-IPv6-Acct-Output-Gigawords
Refer to the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide for
a detailed description of all counter attributes.
• XML accounting
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
config>subscr-mgmt>sla-prof
sla-profile sla-profile-1 create
ingress
ip-filter 100
ipv6-filter 300
exit
egress
ip-filter 200
ipv6-filter 400
exit
exit
Changing the IPv4 filter policy in an SLA profile in use by an active subscriber is
allowed in the CLI, but not recommended. Changing the IPv6 filter policy in an SLA
profile in use by an active subscriber is prevented in the CLI.
Refer to the 7750 SR and VSR RADIUS Attributes Reference Guide for a detailed
description of the RADIUS attributes format.
Refer to the 7750 SR and VSR Gx AVPs Reference Guide for a detailed description
of the Diameter AVP’s format.
Changing the SLA profile of a subscriber host or session, implicitly changes its
associated IP and IPv6 filter policies. An SLA profile change can be done by, for
example, a RADIUS CoA or Diameter Gx RAR message. As the SLA profile also
defines the QoS configuration for the subscriber hosts, this change may result in a
discontinuity in accounting.
The ingress and egress IP and IPv6 filter policies can be overridden per subscriber
host or session at creation time or mid-session:
Notes:
• Irrelevant fields (for example, IPv4 filters for an IPv6 host) are ignored.
• RADIUS CoA message: if the ingress or egress field is missing in the VSA, there
is no change for that direction.
• RADIUS Access-Accept message: if the ingress or egress field is missing in the
VSA, then the IP filters as specified in the SLA profile are active for that direction.
• An SLA profile IP filter override is applicable to all dynamic host types, including
L2TP LNS but excluding L2TP LAC.
A subscriber host specific entry is a filter entry where the match criteria is
automatically extended with the subscriber host IP or IPv6 address as source
(ingress) or destination (egress) IP. They represent a per host customization of a
generic filter policy: only traffic to or from the subscriber host that match against
these entries.
The format used to specify host specific filter entries ([92] NAS-Filter-Rule format or
[26.6527.159] Alc-Ascend-Data-Filter-Host-Spec format) cannot change during the
lifetime of the subscriber host. A RADIUS message can only contain a single format
for host specific filter entries.US message can only contain a single format for host
specific filter entries.
Note that subscriber host-specific filter entries are moved if the subscriber host filter
policy is changed (new SLA profile or IP filter policy override) and the new filter policy
contains enough free reserved entries (sub-insert-radius).
A range of entries must be reserved for subscriber host specific entries in a filter
policy:
config>filter
ip-filter 100 create
sub-insert-radius start-entry 1000 count 100
High and low watermarks can be configured to raise an event when the thresholds
of free entries in the reserved range are reached:
*A:cses-nokia>config>filter>ip-filter$ sub-insert-wmark ?
- no sub-insert-wmark
- sub-insert-wmark low <low-watermark> high <high-watermark>
<low-watermark> : [0..100]
<high-watermark> : [0..100]
The target application for shared filter entries is operators that have a predefined
limited number of different filter lists that each are shared with multiple subscriber
hosts or sessions and that are to be managed and activated from RADIUS or
Diameter at authentication.
For each unique set of dynamic filter entries received per type (IPv4 or IPv6) and
direction (ingress or egress), a copy is made of the local filter with the dynamic
entries included at a preconfigured insert point. If the same set of dynamic filter
entries is sent to subscriber hosts or sessions that have the same associated local
filter, then they share the same filter copy. When there are no more subscriber hosts
associated with a filter copy, then the filter copy is deleted. A filter copy is identified
as local filter id:number. For example: show filter ip 10:2.
Shared filter entries are moved if the subscriber host filter policy is changed (new
SLA profile or ip filter policy override) and if the new filter policy contains enough free
reserved entries.
line 1
CoA1 line 2
Host 1
line 3
CoA2
Host 2 Ingress ip Reserved for
CoA1 filter 10 Shared Filter Lines
Host 3
CoA1 Host-specific Lines
Host 4
Credit-control
al_0174
High and low watermarks can be configured to raise an event when the thresholds
of dynamic filter copies are reached:
*A:cses-V22>config>filter>ip-filter# shared-radius-filter-wmark ?
- no shared-radius-filter-wmark
- shared-radius-filter-wmark low <low-watermark> high <high-watermark>
<low-watermark> : [0..7999]
<high-watermark> : [1..8000]
Use following show commands to check filter policy details and the filter configuration
for a subscriber host:
HGW
DSLAM PE-A VPLS
BSR
Synchronise
DHCP-state
IGMP-snooping
HGW
Arp-reply-agent
PE-B response
OSSG110
9.3.16.1 Overview
Internally, peering-relation and sync-tag are translated into a port and encapsulation
value identifying the object (SAP) that the given entry is associated with. The
application-id then identifies the application which created the entry on one of the
nodes. There are three basic operations that the application can perform on MCS
database. The MCS database always synchronizes these operations with its
respective peer for the given entry.
Each time the connection between the redundant pair nodes is established or re-
established, the MCS database is re-synchronized. There are several levels of
connectivity loss that can have different effects on amount of data lost. To prevent
massive retransmissions when the synchronization connection experiences loss or
excessive delay, the MCS process implementation takes provisions to ensure
following:
• If a reboot of one or both nodes or establishing the peering for the first time, the
full MCS database is reconciled.
• If the MCS communication is lost and then re-established but neither node
rebooted during the connection loss, only the information not synchronized
during this time is reconciled (using sequence numbers helps identify
information which was not synchronized).
• If that MCS communication is lost because of excessive delay in ACK messages
but no information has been effectively lost, the MCS process indicates a loss of
synchronization but no reconciliation is performed.
An active DHCP lease time threshold per multi-chassis peer is determined as the
smallest value configured on either of the redundant BNGs:
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 equalling 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.
Note: The MCS DHCP lease time threshold is not applicable for DHCP server failover
(using the configure redundancy multi-chassis peer sync local-dhcp-server context)
and not applicable for DHCP snooping.
SRRP uses the same messaging format as VRRP with slight modifications. The
source IP address is derived from the system IP address assigned to the local router.
The destination IP address and IP protocol are the same as VRRP (224.0.0.18 and
112, respectively).
The message type field is set to 1 (advertisement) and the protocol version is set to
8 to differentiate SRRP message processing from VRRP message processing.
The vr-id field has been expanded to support an SRRP instance ID of 32 bits.
Due to the large number of subnets backed up by SRRP, only one message every
minute carries the gateway IP addresses associated with the SRRP instance. These
gateway addresses are stored by the local SRRP instance and are compared with
the gateway addresses associated with the local subscriber IP interface.
Unlike VRRP, only two nodes may participate in an SRRP instance due the explicit
association between the SRRP instance group IP interface, the associated
redundant IP interface and the multi-chassis synchronization (MCS) peering. Since
only two nodes are participating, the VRRP skew timer is not utilized when waiting to
enter the 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.
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. Once the peering is associated with the
SRRP instance, MCS synchronizes the local information about the SRRP instance
with the neighbor router. MCS automatically derives the MCS key for the SRRP
instance based on the SRRP instance ID. For example, an SRRP instance ID of 1
would appear in the MCS peering database with a MCS-key srrp-0000000001.
The SRRP instance information stored and sent to the neighbor router consists of:
The SRRP instance uses the received information to verify provisioning and obtain
operational status of the SRRP instance on the neighboring router.
The SRRP instance MCS key ties the received MCS information to the local SRRP
instance with the same MCS key. If the received key does not match an existing
SRRP instance, the MCS information associated with the key is ignored. Once an
SRRP instance is created and mapped to an MCS peering, the SRRP instance
evaluates received information with the same MCS key to verify it corresponds to the
same peering. If the received MCS key is on a different peering than the local MCS
key an SRRP peering mismatch event is generated detailing the SRRP instance ID,
the IP address of the peering the MCS key is received on and the IP address to which
the local MCS key is mapped. If the peering association mismatch is corrected, an
SRRP peering mismatch clear event is generated.
The Containing Service Type is the service type (IES or VPRN) that contains the
local SRRP instance. The Containing Service ID is the service ID of that service. This
information is supplied for troubleshooting purposes only and is not required to be
the same on both nodes.
The containing subscriber IP interface name is the subscriber IP interface name that
contains the SRRP instance and its group IP interface. This information is supplied
for troubleshooting purposes only and is not required to be the same on both nodes.
The subscriber subnet information includes all subscriber subnets backed up by the
SRRP instance. The information for each subnet includes the Owned IP address, the
mask and the gateway IP address. If the received subscriber subnet information
does not match the local subscriber subnet information, an SRRP Subscriber Subnet
Mismatch event is generated describing the SRRP instance ID and the local and
remote node IP addresses. Once the subscriber subnet information matches, an
SRRP Subscriber Subnet Mismatch Clear event is generated.
The containing group IP interface information is the information about the group IP
interface that contains the SRRP instance. The information includes the name of the
group IP interface, the list of all SAPs created on the group IP interface, the
administrative and operational state of each SAP and the MCS key and the peering
destination IP address associated with each SAP. To obtain the MCS information,
the SRRP instance queries MCS to determine the peering association of the SRRP
instance and then queries MCS for each SAP on the group IP interface. If the local
SRRP instance is associated with a different MCS peering than any of the SAPs or
if one or more SAPs are not tied to an MCS peering, an SRRP group interface SAP
peering mismatch event is generated detailing the SRRP instance ID, and the group
IP interface name.
When receiving the remote containing group IP interface information, the local node
compares the received SAP information with the local group IP interface SAP
information. If a local SAP is not included in the SAP information or a remote SAP is
not included in the local group IP interface, an SRRP Remote SAP mismatch event
is generated detailing the SRRP instance ID and the local and remote group IP
interface names. If a received SAP’s MCS key does not match a local SAP's MCS
Key, an SRRP SAP MCS key mismatch event is generated detailing the SRRP
instance ID, the local and remote group IP interface names, the SAP-ID and the local
and remote MCS keys.
If the group IP remote redundant IP interface address space does not exist, is not
within the local routing context for the SRRP instances group IP interface or is not on
a redundant IP interface, the local node sends redundant IP interface unavailable to
prevent the remote neighbor from using its redundant IP interface. An SRRP
redundant IP interface mismatch event is generated for the SRRP instance detailing
the SRRP instance, the local and remote system IP addresses, the local and remote
group IP interface names and the local and remote redundant IP interface names
and IP addresses and masks. The local redundant IP interface may still be used if
the remote node is not sending redundant IP interface unavailable.
If the remote node is sending redundant IP interface unavailable, the local node
treats the local redundant IP interface associated with the SRRP instances group IP
interface as down. A Local Redundant IP Interface Unavailable event is generated
detailing the SRRP instance ID, the local and remote system IP addresses, the local
group IP interface name, the local redundant IP interface name and the redundant IP
interface IP address and mask.
If the remote node’s SRRP advertisement SAP does not exist on the local SRRP
instances group IP interface, the local node sends local receive SRRP advertisement
SAP unavailable to the remote node. An SRRP receive advertisement SAP non-
existent event is generated detailing the SRRP instance ID, the local and remote
system IP addresses, the local group IP interface name and the received remote
SRRP advertisement SAP. Since SRRP advertisement messages cannot be
received, the local node immediately becomes SRRP master if it has the lower
system IP address.
If the local node is receiving local receive SRRP advertisements stating that the SAP
is unavailable from the remote node, an SRRP Remote Receive advertisement SAP
Unavailable event is generated. This details the SRRP instance ID, the local and
remote system IP addresses, the remote group IP interface name and the local
SRRP advertisement SAP. Since the remote node cannot receive SRRP
advertisement messages, the local node immediately becomes SRRP master if it
has the lower system IP address.
If both local and remote SRRP instances are in master states, then an SRRP dual
master event is generated detailing the SRRP instance ID and the local, remote
system IP addresses and the local and remote group IP interface names and port
numbers.
In order for the network to reliably reach the owned IP addresses on a subscriber
subnet, the owning node must advertise the IP addresses as /32 host routes into the
core. This is important since the subscriber subnet is advertised into the core by
multiple routers and the network follows the shortest path to the closest available
router which may not own the IP address if the /32 is not advertised within the IGP.
The group IP interface SAPs are designed to support subscriber hosts and perform
an ingress anti-spoof function that ensures that any IP packet received on the group
IP interface is coming in the correct SAP with the correct MAC address. If the IP and
MAC are not registered as valid subscriber hosts on the SAP, the packet is silently
discarded. Since the SRRP advertisement source IP addresses are not subscriber
hosts, an anti-spoof entry cannot exist and SRRP advertisement messages would
normally be silently discarded. To avoid this issue, when a group IP interface SAP is
configured to send and receive SRRP advertisement messages, anti-spoof
processing on the SAP is disabled. This precludes subscriber host management on
the SRRP messaging SAP.
But it is not necessary that an entire BNG fails before it triggers the corrective action.
The solution outlined in this document includes protection against interfaces and line
card failures within the BNG. The redundant (protective) entity, however, does not
reside within the same BNG on which the failure occurs but instead it is on a separate
BNG node.
Upon a switchover, a gratuitous ARP is sent from a newly selected active node so
that each IPoE client can update the ARP table, if the MAC address has indeed
changed (it does not have to). More importantly, if an Layer 2 aggregation network is
in place between the BNG and the IPoE client, all intermediate Layer 2 devices must
update their port-to-mac mappings (Layer 2 FDB). The above described process
ensures proper packet addressing on the IPoE client side as well as the proper
forwarding path through Layer 2 aggregation network to the newly activated BNG.
When considering PPPoE in conjunction with SRRP, keep in mind that PPP protocol
(point-to-point protocol) is adopted for the Ethernet (shared medium) by enabling an
extra Ethernet related layer in PPP that allows sharing of point-to-point sessions over
Ethernet (shared medium). The result is a PPPoE protocol designed to ‘tunnel’ each
PPP session over Ethernet.
PPPoE is not aware of ARP (Address Resolution Protocol) and it does not react to
gratuitous ARP packets sent by a newly active BNG. The destination MAC address
that PPPoE clients use when sending traffic is determined not by ARP but by the
PPPoE Discovery phase at the beginning of the session establishment. This
originally discovered destination MAC is used throughout the lifetime of the session.
This has a couple of consequences:
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. Since 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. Since 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
- In the upstream direction, the active SRRP node accepts subscriber traffic
addressed either to the MAC address of the SRRP active group OR the
native interface MAC address.
- The standby node accepts in the upstream direction only packets
addressed to its native interface MAC address.
3. If both SRRP nodes become active (SRRP master state), then both forward
traffic to or from subscribers unaware of the link failure somewhere in the Layer
2 network. As a result, downstream traffic can be blackholed. Whether
downstream traffic is lost depends on the native routing on the network side,
which is unaware of the failures in the aggregation network.
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.
BNG 1
GRP 1
CPEs Active
Access SRRP 10
Node
SubIntf IP@
GRP 2
Standby
,3
1,2
SRRP 20
AN
6
5,
VL
4,
AN
VL
BNG 2
AN
AN
4,5
1,2
,6
CPEs
,3
Access
Node
GRP 2
Active
SRRP 20
SubIntf IP@
GRP 1
Standby
SRRP 10
To preserve QoS and Accounting, subscriber’s traffic must flow in both directions
through the multi-chassis 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 collocated. 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 towards 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
Traffic destined to or from the subscriber is forwarded under the condition that the
subscriber-interface is operationally UP. This applies also to shunting of downstream
subscriber traffic from the standby (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.
A single IP subnet is used for all subscribers terminated within the redundant BNG
nodes. The upside of the Option ‘A’ is that it offers aggregated IP addressing in the
network core per pair of redundant BNG nodes. The downside is that the subscriber
termination point (active BNG for the SRRP group) is hidden from the network core.
Since both BNG nodes share the same IP subnet for the subscribers, the natural
routing can cause downstream traffic to be sent to the standby BNG which must
shunt the traffic to the active BNG. It is likely that half of the traffic is shunted over the
redundant-interface with this approach. This scenario is shown in Figure 94.
IGPvertiz
Ad
STBY
10.
/BG e
0.0
P
.0/1
6
CPEs
Access
Node
Redundant
VPLS SRRP CORE
Interface
BNG 2
rtiz P
grp-if 1 SubIntf IP@
e
Ad P/BG
/16
SRRP 10 10.0.0.1/16
CPEs
ve
0.0
IG
Access STBY
.0.
Node
10
+
Only One
grp-if 2
Aggregated
SRRP 20 Route Per
Pair of BNGs
ACT
–
High Traffic
Over the
Redundant
Traffic Flow
Interface
Traffic Flow
After a Fallover
al_0048
With the option B, an IP address pool (or subnet) can be allocated per group of SRRP
instances that are in the SRRP master state. The routing decision on the network
side is further influenced by the static increase of the metric of the advertised route
on the BNG node hosting the active SRRP groups (Figure 95).
This approach would cause greater IP space segmentation in the network core, but
at the same time, it would indirectly provide more information about the subscriber
whereabouts and thus minimize or eliminate the shunt traffic during the normal
operation. However, if an SRRP switchover occurs, the shunt traffic would ensue.
The amount of the shunted traffic would depend on the scale of the failure. From the
configuration displayed in Figure 95, it can be concluded that:
10. 0.0.0 24 W
11. .0.0/
STBY
12.
0.0 /24
IGPvertiz
0
.0/2 Wi h Hig
Ad
grp-if 3
4 W th L her
/BG
SRRP 30
P
it
Hig r P f
e
ACT
her ref
Pre
CPEs
f
Access
Node
Redundant CORE
VPLS SRRP
Interface
Lo wer Pref
BNG 2
r P ef
rtiz P
ref
we Pr
grp-if 1
Wi h Lo her
e
SubIntf IP@
Ad P/BG
SRRP 10 10.0.0.1/24
ve
CPEs
ith
IG
11.0.0.1/24
.0. 0/2 W
th
Node
0
10 .0.0.
grp-if 2
11
.
SRRP 20 +
No Traffic
ACT Over the
Redundant
Interface
grp-if 3
–
SRRP 30
Multiple Routes
STBY Per Pair
Traffic Flow of BNGs
Manual Routing
Traffic Flow
Policy Creation
After a Fallover
al_0049
As per RFC 2516, A Method for Transmitting PPP Over Ethernet (PPPoE), this has
the implications on the operation of the capture SAP. In an IPoE environment, the
initial DHCP traffic related to host establishment uses its native MAC of the physical
port on the router. Once the group interface is learned (later in the process, by
RADIUS or msap-policy), the MAC address is switched to SRRP MAC address
(virtual MAC). The IPoE client adapts easily to this change. On the contrary, for the
proper operation of PPPoE with SRRP, the initial destination MAC address learned
by the PPPoE client does not change during the lifetime of the session.
This is ensured by indirectly referencing the grp-if under the capture SAP:
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.
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.
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 to/from the subscriber is forwarded under the condition that the
subscriber-interface is operationally UP. This applies also to shunting of downstream
subscriber traffic from the standby (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.
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.
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.
• 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 proper 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 first gets 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 unicasted 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>
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:
subscriber-interface <ip-int-name>
group-interface <ip-int-name>
dhcp
server <local-dhcp-ip-address> <remote-dhcp-ip-address>
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.
On regular interfaces in an IES or VPRN service, only one SAP can be associated.
A group interface allows multiple SAPs to be configured as part of a single interface.
All SAPs in a single group interface must be within the same port. Since broadcast
is not allowed in this mode, forwarding to the subscriber is based on IP/MAC
addresses information gathered by the subscriber management module and stored
in the subscriber management table. These entries are based on both static and
dynamic DHCP hosts. Routed CO must be used with standard subscriber
management or enhanced subscriber management. DSLAMs are typically deployed
with Ethernet interfaces.
This model is a combination of two key technologies, subscriber interfaces and group
interfaces. While the subscriber interface define the subscriber subnets, the group
interfaces are responsible for aggregating the SAPs.
As depicted in Figure 96, an operator can create a new subscriber interface in the
IES or VPRN service. A subscriber interface allows for the creation of multiple group
interfaces. The IP space is defined by the subnets of the subscriber interface’s
addresses. Figure 97 shows the details of group interface A.
7750 X
VPRN X
Subscriber
Group Table
DSLAM A Interface
A
Subscriber
Interface A
Group
DSLAM B Interface
B
Subscriber
Interface B
Group
DSLAM C Interface
C
OSSG099
SAP 1
SAP 2 Group
A Interface
A
SAP n
OSSG301
Figure 98 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).
HGW
DSLAM
BSR
HGW
BSR IP Network
HGW
DSLAM BSR
HGW
OSSG089
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.
Route IGP
DSLAM
Policies Messages
RTM IGP
1/1/1
Group Adv {none| own| all|}
Intf_1
SUBSCRIBER 1/1/3
Service Network
Subnet
ies 1 Intf
10.10.1.1/16
Group
DSLAM Intf_2
1/1/2
BSR
OSSG090
• 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
Figure 99) 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.
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 DHCP relay process has been enhanced to record incoming DHCP discover and
request messages. Since forwarding to the SAPs is done by the information in the
subscriber management table and multiple SAPs are allowed in one interface it was
impossible to know which SAP is used to forward the DHCP replies. The node
maintains a cache of the DHCP requests. The cache can be viewed using the
tools>dump>router>dhcp>group-if-mapping command. The cache holds an
entry for 30 seconds. If an ACK/NAK packet was not received from the server within
the timeout the node discards the cache entry. The node can use the Option 82
circuit-id field as part of the temporary host entry. If used, the ACK must contain the
same circuit-id field in Option 82 to be found in the cache only if the match-circuit-id
is specified at the DHCP level of the group- interface. When the match-circuit-id
command is enabled a check is performed for option 82 circuit-id.
When a DHCP ACK is received the IP address provided to the client is verified to be
in one of the subscriber subnets associated with the egress SAP. When DHCP
snooping is enabled for regular IES interfaces the same rule applies.
In the routed CO model, the router acts as a DHCP relay agent and also serves as
the subscriber- identification agent. The DHCP actions are defined in the group
interface. All SAPs in that interface inherit these definitions. The group interface
DHCP definition are a template for all SAPs.
When an authentication policy is specified for a SAP under a group interface, DHCP
intercepts DHCP discover messages for RADIUS authentication. If the system is a
DHCP-relay defined in a group interface and the GI address was not configured, the
operational state of DHCP is down.
Much like in Routed CO for IES service, the Routed CO model for VPRN depends
on subscriber management to maintain the subscriber host information. To create a
group interface, the operator must first create a subscriber interface in the
config>service>vprn context. The subscriber interface can maintain up to 256
subscriber subnets and can be configured with a host address for each subnet. The
host IP address can be installed as a result of both relaying to a DHCP server and
proxy to a RADIUS server. In both cases the host IP address must be in the subnet
defined by the VPRN’s subscriber interface.
The node can be defined with both a DHCP relay or proxy function. If the user
configures a DHCP relay, the local-proxy-server command enables DHCP split
leases. In that configuration the node provides the configured DHCP lease to the
client using either RADIUS or the real DHCP server as the source of the IP address
to be provided.
The RADIUS server can send a Change of Authorization (CoA) message containing
the DHCP FORCERENEW VSA which prompts the local-proxy-server to send a
FORCERENEW message to the client. The node ACKs when the FORCERENEW
messages has been sent, regardless of whether the subscriber responds. If the client
fails to respond or if a new session cannot be established due to resource
management issues or otherwise the node must respond with a NACK to the
RADIUS server.
If the CoA message contains an IP address that is different than the configured IP
address (when RADIUS was providing IP addresses) the node must send a
FORCERENEW message to the client and NAK the request and provide a new IP
address. If the node fails to receive a request, the CoA is ACK’d when the
FORCERENEW message has been sent.
The operational state of group and subscriber interfaces are dependent on the state
of active SAPs. A group interface can become operationally up only if at least one
SAP is configured and is in an operationally up state. A subscriber interface becomes
operationally up if at least one group interface is operationally up or the associated
wholesale forwarding interface is operationally up. This ensures that, in a failure
scenario that affects all group interfaces in a given subscriber subnet, the node stops
advertising the subnet to the network. The SRRP state affects this behavior as well
and can cause the subnet to be removed if all group interfaces (and SRRP instances)
are in backup state.
In the wholesale retail model (Figure 100), the wholesaler instance connections that
are common to the access nodes are distributed to many retail instances. A
subscriber host attached to an access node connected in the wholesaler service can
be instantiated in a retail service and obtain IP addresses from the retailers address
space. The service context of the retailer is determined during the subscriber host
authentication phase (for example, by the Alc-Retail-Serv-Id attribute and Alc-Retail-
Serv-Name attribute in RADIUS or the retail-service-id CLI in the local user
database).
Upstream subscriber traffic ingresses into the wholesaler instance and after
identification is then forwarded into the retail instance. The reverse occurs for traffic
in the downstream direction.
Wholesale VPRN
Group Retail VPRN 2
Access (M-)SAP
Node 1 Interface 1 Subscriber Subscriber Service
Interface Interface Provider 2
Group
(M-)SAP
Interface m
al_0622
In a wholesale retail model, two subscriber interfaces must be configured and linked
together: one in the wholesale VPRN and one in the retail service.
The wholesale subscriber interface defines the IP subnets and host specific
configuration parameters for subscriber hosts belonging to the wholesaler. There are
associated group interfaces that contain the SAPs which connect to the access
nodes.
The retail subscriber interface defines the IP subnets and host specific configuration
parameters for subscriber hosts belonging to the retailer. The retail subscriber
interface is linked to a wholesale subscriber interface for forwarding by explicit
configuration. There are no associated group interfaces.
For example:
config>service
vprn 1000 customer 1 create
subscriber-interface "sub-int-ws-1" create
# wholesale subscriber interface
--- snip ---
group-interface "group-int-1-1" create
--- snip ---
sap 1/1/1:1 create
--- snip ---
exit
exit
exit
exit
exit
exit
As explained in the previous section, the wholesale retail model is provisioned with
the linking of a subscriber interface in a retail service to a subscriber interface in the
wholesale VPRN service.
Because a retail subscriber interface does not have a group interface context, some
group interface-specific CLI parameters such as to configure dhcp relay are made
available at the retail subscriber interface level. Other CLI parameters such as to
provision RADIUS or local user database authentication are configured at the
wholesale subscriber or group interface and apply to both wholesale and retail
subscriber hosts.
Only the service configurations are shown. They have to be completed with
authentication policies and subscriber management configuration such as radius-
server-policies, sub- and sla-profiles, and so on.
config>service
config>service>
vprn 4001 customer 1 create
autonomous-system 64501
route-distinguisher 64500:4001
auto-bind-tunnel
resolution-filter
ldp
rsvp
exit
resolution filter
exit
vrf-target target:64500:4001
interface "int-loopback-1" create
address 192.0.2.5/32
ipv6
address 2001:db8::5/128
exit
loopback
exit
subscriber-interface "sub-int-rt-4000-1" fwd-service 4000 fwd-
subscriber-
interface "sub-int-1" create
address 10.10.11.254/24
address 10.10.12.254/24
dhcp
server 192.0.2.4
lease-populate 100
gi-address 10.10.11.254
no shutdown
exit
ipv6
subscriber-prefixes
prefix 2001:db8:b:100::/56 wan-host
prefix 2001:db8:b001::/48 pd
exit
dhcp6
relay
source-address 2001:db8::5
server 2001:db8::4
no shutdown
exit
exit
router-advertisements
no shutdown
exit
exit
exit
no shutdown
exit
The wholesale retail model applies to all IPoE, PPPoE PTA, IPv4 and IPv6 host
types.
The wholesale service type must be VPRN. For IPoEv4 hosts, the retail service type
must be a VPRN. For all other host types, the retail service type can be IES or VPRN.
The wholesale retail model can be deployed in combination with managed SAPs.
Overlapping subscriber subnets and prefixes in retail VPRN services associated with
the same wholesale forwarding service are supported for PPPoE (IPv4 and IPv6)
and IPoE (IPv4 and IPv6). This support is enabled by configuring private retail
subnets on the retail subscriber interface. Private retail subnets are supported when
multi-chassis redundancy is needed.
Figure 101 shows user-to-user traffic forwarding for both retail VPRN types: regular
and subscriber-split-horizon.
Framed-Route
Framed-IPv6-Route
2001:db8:1:1:100::/56
VRF
2001:db8:0:1::1/64 sub-int
2001:db8:1:200::/56 group-int
10.1.1.1/24
MSAN SAP
Routed
172.16.1.0/24 Subscriber
BNG
Associated/Managed
Routes Dynamic BGP Peer
sw0010
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:
The routes associated with a static host are populated in the routing table as
“Remote Managed” routes. Up to sixteen managed routes can be configured for a
static host.
Classic CLI
config>service>ies>sub-if>grp-if>sap
config>service>vprn>sub-if>grp-if>sap
static-host ip 10.1.1.20 create
sla-profile "sla-profile-1"
sub-profile "sub-profile-1"
subscriber "static-host-1"
managed-routes
route-entry 172.20.1.0/24 create
metric 10
preference 5
tag 100
exit
...
route-entry 172.20.16.0/24 create
metric 10
preference 5
tag 100
exit
exit
no shutdown
exit
MD-CLI
To display the managed routes associated with a routed subscriber host, use
following commands:
The routes associated with a static host are populated in the routing table as
“Remote Managed” routes. Up to sixteen managed routes can be configured for a
static host.
Classic CLI
config>service>ies>sub-if>grp-if>sap
config>service>vprn>sub-if>grp-if>sap
anti-spoof nh-mac
static-host ip 2001::1/128 create
sla-profile "sla-profile-1"
sub-profile "sub-profile-1"
subscriber "static-host-1"
managed-routes
route-entry 2000::/56 create
metric 10
preference 5
tag 100
exit
...
route-entry 3000::/56 create
metric 10
preference 5
tag 100
exit
exit
no shutdown
exit
To display the managed routes associated with a routed subscriber host, use the
show>service>id service-id>static-host detail command.
MD-CLI
sla-profile "sla-profile-1"
subscriber-id {
string "static-host-1"
}
managed-route 2000::/56 {
metric 10
preference 5
tag 100
}
...
managed-route 3000::/56 {
metric 10
preference 5
tag 100
}
}
}
An ESM dynamic BGP peer setup is automatic when a BGP peering policy attribute
is received during RADIUS authentication of a routed subscriber host. The BGP peer
is torn down and the associated routes removed from the routing table when the
subscriber host is removed from the system (for example, because of a lease timeout
or log out).
An ESM dynamic BGPv4 peer supports the IPv4 address family to exchange IPv4
routes and an ESM dynamic BGPv6 peer supports the IPv6 address family to
exchange IPv6 routes. When both IPv4 and IPv6 routes must be exchanged, dual-
stack routed subscriber sessions require two dynamic BGP peers, one for each
address family.
ESM dynamic BGP peering is supported for routed subscriber hosts terminated in a
VPRN service and is not supported for hosts terminated in an IES service. ESM
dynamic BGP peering is supported in a wholesale and retail deployment.
The BGP learned routes scaling is limited by the BGP scaling limits. The routes
learned by a dynamic BGP peer are populated in the routing table as remote BGP
routes.
Pre-requisites:
An ESM dynamic BGPv4 peer is established for a routed subscriber host if the
26.6527.55 Alc-BGP-Policy VSA returned in a RADIUS Access-Accept message
contains the name of a local configured BGP peering policy and an ESM dynamic
peer group is configured in the VPRN BGP context, as shown in the following classic
CLI example.
config>subscr-mgmt
bgp-peering-policy "bgpv4-policy-1" create
local-address 10.3.2.254
local-as 65536
peer-as 65501
type external
exit
config>service>vprn
bgp
group "esm-dyn-peer-group-1" esm-dynamic-peer
exit
no shutdown
exit
The subscriber host IPv4 address is used as the BGP peer IP address.
The local address can be the subscriber interface IPv4 address (single hop BGP
peer) or a loopback interface IPv4 address (multi-hop BGP peer).
See BGP Peering Parameters for more information about how the other BGP peering
parameters can be specified and Import and Export Policies for ESM Dynamic BGP
Peers for more information about route policies.
To verify that an ESM dynamic BGPv4 peer is correctly installed, use the following
show commands:
Example output:
To verify the state of an ESM dynamic BGPv4 peer, use the show router router-
instance bgp summary command.
Pre-requisites:
An ESM dynamic BGPv6 peer is established for a routed subscriber host if the
26.6527.208 Alc-BGP-IPv6-Policy VSA returned in a RADIUS Access-Accept
message contains the name of a local configured BGP peering policy and an ESM
dynamic peer group is configured in the VPRN BGP context, as shown in the
following classic CLI example.
config>subscr-mgmt
bgp-peering-policy "bgpv6-policy-1" create
local-address 2001:db8:b002:201::1
local-as 65536
peer-as 65501
type external
exit
config>service>vprn
bgp
group "esm-dyn-peer-group-1" esm-dynamic-peer
exit
no shutdown
exit
[pr:/configure subscriber-mgmt]
bgp-peering-policy "bgpv6-policy-1" {
local-address 2001:db8:b002:201::1
peer-as 65501
type external
local-as {
as-number 65536
}
}
The subscriber host IPv6 WAN address is used as the BGP peer IP address. Both
SLAAC and DHCPv6 IA_NA addresses are supported.
For a SLAAC host, the BGP mode on the subscriber side must be active, that is the
router at the subscriber premises should initiate the BGP TCP connection, such that
the BNG can snoop the TCP SYN and derive the /128 Global Unicast Address of the
SLAAC host as the BGP peer address.
ESM dynamic BGP peering is not supported for a DHCPv6 IA_PD host.
The local address can be the subscriber interface IPv6 address (single hop BGP
peer) or a loopback interface IPv6 address (multi-hop BGP peer).
See BGP Peering Parameters for more information about how to configure other
BGP peering parameters and Import and Export Policies for ESM Dynamic BGP
Peers for more information about route policies.
To verify that an ESM dynamic BGPv6 peer is correctly installed, use the following
show commands.
Example output:
To verify the state of an ESM dynamic BGPv6 peer, use the show router router-
instance bgp summary command.
ESM dynamic BGP peering parameters can be specified from multiple sources:
• Use BGP peering parameters returned in RADIUS VSAs; see Table 27 and
RADIUS Attributes Reference Guide for more details.
• If not available from RADIUS, use BGP peering parameters configured in the
bgp-peering-policy.
• If not configured in the bgp-peering-policy, use BGP peering parameters
configured for the esm-dynamic-peer group.
• If not configured in the esm-dynamic-peer group, use the BGP peering
parameters configured in the VPRN service BGP CLI context.
• If not configured in the VPRN service BGP CLI context, use the defaults.
The import and export policies used for the ESM dynamic BGP peer are determined
in the following priority order:
1. Use import or export policies returned in RADIUS VSA's. These are appended
to the policies configured in the bgp-peering-policy. A single import and a
single export policy can be returned from RADIUS. A maximum of 15 policies
can be active per peer. When 15 policies are configured in the bgp-peering-
policy, the last policy is replaced with the RADIUS returned policy.
2. If not available from RADIUS and not configured in the bgp-peering-policy, use
the policies configured in the esm-dynamic-peer group.
3. If not configured in the esm-dynamic-peer group, use the policies configured in
the VPRN service BGP CLI context.
To display the BGP learned routes associated with a routed subscriber host, use the
BGP show commands; for example: show router router-instance bgp neighbor ip-
address received-routes.
Fast Failure Detection for ESM Dynamic BGP Peers using BFD
BGP peer failure detection is by default based on the keep-alive and hold time. For
cases where fast failure detection is needed, a BFD session can be used to control
the operational state of the BGP peer. Fast failure detection for ESM dynamic BGP
peers using BFD is supported for IPoE and PPPoE subscribers. It is not supported
for L2TP LNS subscribers.
BFD for ESM dynamic BGP peers is enabled in the bgp-peering-policy in classic
CLI.
config>subscr-mgmt
BFD for ESM dynamic BGP peers is enabled in the BGP peering policy in MD-CLI.
[pr:/configure subscriber-mgmt]
bgp-peering-policy "bgpv4-policy-1" {
bfd-liveness true
local-address 10.3.2.254
peer-as 65501
type external
local-as {
as-number 65536
}
}
The parameters for the BFD sessions must be configured on the group interface or
retail subscriber interface in classic CLI.
config>service>vprn>sub-if>grp-ifconfig>service>vprn>sub-if
bfd 100 receive 100 multiplier 3
ipv6
bfd 100 receive 100 multiplier 3
exit
The parameters for the BFD sessions must be configured on the group interface or
retail subscriber interface in MD-CLI.
ipv6 {
bfd {
admin-state enable
transmit-interval 100
receive 100
multiplier 3
}
}
The BFD session is always established as a single hop BFD session and therefore
fast-failure detection using BFD works for single hop ESM dynamic BGP peers only.
The local address for the BGP peer must be a local IPv4 or IPv6 address configured
on the subscriber interface.
To verify the state of the BFD session, use the show commands in the following
output examples:
A:pe2# show router 2000 bfd session dest 2001:db8:b002:201::aaa:1 src 2001:db8:b002:
201::1
===============================================================================
BFD Session
===============================================================================
Remote Address : 2001:db8:b002:201::aaa:1
Local Address : 2001:db8:b002:201::1
Admin State : Up Oper State : Up
Protocols : bgp
Rx Interval : 100 Tx Interval : 100
Multiplier : 3 Echo Interval : 0
Recd Msgs : 2988898 Sent Msgs : 2988679
Up Time : 2d 16:46:10 Up Transitions : 1
Down Time : None Down Transitions : 0
Version Mismatch : 0
Forwarding Information
Local Discr : 23 Local State : Up
Local Diag : 0 (None) Local Mode : Async
Local Min Tx : 100 Local Mult : 3
Last Sent : 08/23/2021 08:18:43 Local Min Rx : 100
Type : iom
Remote Discr : 19 Remote State : Up
Remote Diag : 0 (None) Remote Mode : Async
Remote Min Tx : 100 Remote Mult : 3
Remote C-flag : 1
Last Recv : 08/23/2021 08:18:43 Remote Min Rx : 100
===============================================================================
===============================================================================
The following events are generated for a BFD protected ESM dynamic BGP peer.
• BFD session to track the ESM dynamic BGP peer with peer address
2001:db8:b002:201::aaa:1 is up. This indicates that the ESM dynamic BGP peer
is tracked by the BFD session and fast failure detection is enabled:
2604 2021/08/20 15:32:33.507 UTC MINOR: VRTR #2062 vprn2000
2001:db8:b002:201::aaa:1 "BFD: Local Discriminator 23 BFD session on node
2001:db8:b002:201::aaa:1 is up"
If a routed subscriber host is associated with a RIP policy, the host’s IPv4 routes can
be learned over RIP. The BNG only supports RIP listener and does not support
sending RIP routes to subscribers. To enable RIP for a subscriber, the subscriber
must first be associated with a rip-policy. The group interface of the subscriber must
also be configured as a RIP neighbor. The RIP policy can be associated to the
subscriber during authentication from LUDB or by RADIUS. It can also be configured
directly for static hosts. The RIP routes learned from a subscriber is removed as a
subscriber is purged or shut down from the system. RIP listening for ESM host is
supported on both IES and VPRN.
To display the RIP learned routes associated with a routed subscriber host, use the
RIP commands. For example:
The group interface must be configured in the RIP CLI context of the routed instance
where the subscriber host is created:
config>router/service vprn>rip
group “rip-listener”
neighbor “group-interface-01”
config>sub-mgmt
rip-policy “rip-policy-01” create
A RIP neighbor is established for a subscriber host if the RADIUS attribute [26-6527-
207] “Alc-RIP-Policy” is returned in the Access-Accept or in LUDB. RIP parameters
such as authentication key and type can be specified in the RIP policy.
For more information about RIP, refer to the 7450 ESS, 7750 SR, 7950 XRS, and
VSR Unicast Routing Protocols Guide.
where:
“::” and “0:0:0:0:0:0:0:0” are automatically interpreted as the wan-host IPv6 address
for managed IPv6 routes.
[<metric>] — Optional. Installed in the routing table as the metric of the managed
route. If not specified, metric zero is used. Value = [0 to 65535].
[tag <tag-value>] — Optional. The managed route is tagged for use in routing
policies. If not specified, or tag-value = 0, then the route is not tagged. Value = [0 to
4294967295].
If the optional metrics (metric, tag and/or preference) are specified in a wrong format
or with out of range values, then the defaults are used for all metrics: metric=0, no
tag and preference=0. No event is logged.
The maximum number of equal cost paths in a routing instance is configured with:
config>router>
config>service>vprn>
ecmp <max-ecmp-routes>
• Identical prefix
• Equal lowest preference
• Equal lowest metric
To display the managed routes associated with a routed subscriber host, use
following commands:
configure
subscriber-mgmt
radius-accounting-policy <name>
include-radius-attribute
framed-route
framed-ipv6-route
Associated managed routes for an instantiated routed subscriber host are included
in RADIUS accounting messages independent of the state of the managed route
(Installed, Shadowed, HostInactive, and so on).
This section describes VPRN leaking and GRT lookup and routed CO in a VPRN.
Subscriber prefixes and prefix delegation, RADIUS, RIP, and BGP-managed routes
with a subscriber prefix as next-hop can be leaked between VPRN services on the
same router using MP-BGP import and export policies.
GRT lookup allows routing from a VPRN to the GRT, and GRT leaking allows routing
from the GRT to a VPRN. These features are particularly useful when VPRNs require
routing to the Internet and the GRT already contains the Internet routing table.
Wholesale/retail VPRNs and the routed CO VPRN have both GRT lookup and GRT
leaking support.
GRT lookup supports traffic from the subscriber to be routed upstream to the GRT.
The following configurations are supported in an upstream direction:
Not Supported
IP/MPLS
Core
BSR-1 BSR-2
IP/MPLS
Metro
BSA-1 BSA-2
Fig_40
Figure 103 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.
Configurations include:
IP/MPLS
Core
BSR-1 BSR-2
VRRP
Spoke -sdp Spoke -sdp
Mesh-sdp
MCS
BSA-1 BSA-2
Fig_39
From a configuration point of view in this model, it is assumed that all subscriber
management features are enabled at the BSA level and that synchronization of the
information (using multi-chassis synchronization) is configured between redundant
pair nodes (BSA-1 and BSA-2 shown in Layer 2 CO Dual Homing - Network
Diagram). The multi-chassis synchronization connection is used only for
synchronizing active subscriber host database and operates independently from
dual-homing connectivity control. At the BSR level, there are no subscriber
management features enabled.
The operation of redundancy at the BSR level through VRRP is the same as dual
homing based on MC-LAG. The operation of dual homing at BSA level is based on
two mechanisms. Ring control connection between two BSAs have two components,
in-band and out-of-band communication. With in-band communication, BFD session
between BSA-1 and BSA-2 running through the access ring and using dedicated
IES/VPRN interface configured on both nodes. This connection uses a separate
VLAN throughout the ring. The access nodes provides transparent bridging for this
VLAN. The BFD session is used to continuously verify the integrity of the ring and to
detect a failure somewhere in the ring.
Figure 105 illustrates the operation of the dual-homed ring. The steady state is
achieved when both nodes are configured in a consistent way and the peering
relation is up. The multi-chassis ring must be provisioned consistently between two
nodes.
In-Band Ring Control Connection (IB-RCC) is in operational UP state. Note that this
connection is set up using a bi-directional forwarding session between IP interfaces
on BSA-1 and BSA-2.
RNCV
RNCV
IB-RCC
Fig_37
In Figure 105, the ring is fully closed and every access node has two possible paths
towards the VPLS core. Figure 105 refers to these as path-a and path-b. To avoid
the loop created by the ring, only one of the paths can be used by any given ring node
for any given VLAN. The assignment of the individual VLANs to path-a or path-b,
respectively, has to be provisioned on both BSAs.
The selection of the primary BSA for both paths is based on the IP address of the
interface used for IB-RCC communication (bi-directional forwarding session). The
BSA with the lower IP address of the interface used as IB-RCC channel becomes 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:
• All SAPs that belong to the path where the given 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 given 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.
All SAPs that belong to a BSA’s path, the standby is operationally down and all FDB
entries of subscriber hosts associated with those SAPs point towards the SDP
connecting to the primary BSA (also called a shunt SDP).
Figure 106 illustrates the model with a broken ring (link failure or ring node failure).
This state is reached in following conditions:
In this scenario, every ring node has only one access path towards the VPLS core
and hence, the Path-a and Path-b notion has no meaning in this situation.
Functionally, both BSAs are now the 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.
RNCV
RNCV
Fig_38
The mapping of individual subscriber hosts into the individual ring nodes is
complicated, especially in the VLAN-per-service model where a single SAP can
represent all nodes on the ring. In this case, a given BSA can have subscriber hosts
associated with the given SAP that are behind reachable ring nodes as well as
subscriber hosts behind un-reachable ring nodes. This means that the given SAP
cannot be placed in an operationally down state (as in a closed ring state), but rather,
selectively re-direct unreachable subscriber states to the shunt SDP.
All SAPs remain in an operationally up state if the ring remains broken. This mainly
applies for BTV SAPs that do not have any subscriber hosts associated with and do
not belong to any particular ring node.
To make the mapping of the subscriber-hosts on the given ring node automatically
provisioned, the ring node identity is extracted during subscriber authentication
process from RADIUS or from a Python script. The subscriber hosts which are
mapped to non-existing ring node remain attached to the SAP.
At the time both BSA detect the break in IB-RCC communication (if BFD session
goes down) following actions are taken:
• Both nodes trigger a RNCV check towards 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 given 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 given SAP(s), the
node sends out FDB population messages to ensure that new path towards 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 multi-chassis ring operates in a revertive mode. This means that
whenever the ring connectivity is restored, the BSA with lower IP address in the IB-
RCC communication channel become primary for the path-a and vice versa for path-
b.
The multi-chassis ring can operate only if both nodes similarly configured. The
peering relation must be configured and both nodes must be reachable at IP level.
The multi-chassis ring with a corresponding sync-tag as a ring-name identifying a
local port ID must be provision on both nodes. And the BFD session and
corresponding interfaces must be configured consistently.
If the multi-chassis rings are not provisioned consistently, the ring does not become
operational and the SAP managed by it is in an operationally up state on both nodes.
• By default, all SAPs (and hence all VLANs on the given port) are assigned to
path-a.
• An explicit statement defining the given VLAN range assigns all SAPs falling into
this range to the path-b.
• An explicit statement defining the given VLAN range defines all SAPs that are
excluded from the multi-chassis 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.
redundant-inf
BSR-1 BSR-2
SRRP-1
DSLAM-1
al_0175
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 (SRRP) chapter.
9.3.20.7 MC Services
PE
MC-L3VPN
MCS
BSR-1 BSR-2 vprn-inf “mc-ring-1”
vprn-inf “mc-ring-1” vlan1001
vlan1001
IGMP-join
Dslam-2
IGMP
PIM
IGMP-join
Dslam-1
IGMP-join
OSSG253
The IGMP is used to register joins and leaves of the user. IGMP messaging between
BSRs is used to determine which router performs the querier role (BSR2 in
Figure 108). PIM is used to determine which router is the designated router and the
router that sends MC streams on the ring.
The access nodes have IGMP snooping enabled and from IGMP messaging
between BSR, they are aware which router is the querier. In the most generic case,
IGMP snooping agents (in access nodes) send the IGMP-joins messages only to
IGMP-querier. The synchronization of the IGMP entries can be then be performed
through MCS. In some cases, access nodes can be configured in such a way that
both ring ports are considered as m-router ports and IGMP joins are sent in both
directions.
All of the above is a steady state operation which is transparent to the topology used
in a Layer 2 domain.
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.
PE
MC-L3VPN
IGMP-join (ch2)
Dslam-2
Dslam-1
OSSG254
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 rather than 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 given subscriber at a time. Dual homing involves several
components:
• Redundant Interface — This is used to shunt traffic to the active node for a given
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.
If SRRP is configured before the redundant interface is up, and in backup state the
router forwards packets to the access node using the backup interface but does not
use the gateway MAC address. This applies to failures in the redundant interface as
well. If the redundant interface exists and up the router sends downstream packets
to the redundant interface and not use the backup group interface.
In a dual homing architecture the nodes must be configured with SRRP to support
redundant paths to the access node. The nodes must also be configured to
synchronize subscriber data and IGMP state. To facilitate data forwarding between
the nodes in case some of the ports in a given subscriber subnet are affected a
redundant interface must be created and configured with a spoke. The redundant
interface is associated with one or more group interfaces.
The service IDs for both the wholesale VPRN and the retailer VPRN must be the
same in both nodes.
An interface in a backup state uses the redundant interface to send traffic to the
active interface (in the active node). The SAP structure under the group interface
must be the same on both nodes as the synchronization of subscriber information is
enabled on a group interface basis.
SRRP is associated a group interface. Multiple group interfaces can be created for a
specific port so that some of the SAPs are active in one node and others active on
the other node. While every SRRP pair is still allowed to be active or backup the
described configuration allows for load balancing between the nodes. In a failure
scenario, subscriber bandwidth is affected.
Wholesaler Retail
VPRN VPRN
Retail
7750 VPRN
SR-7/SR-12
SRRP SRRP Master State
DSLM
Redundant
Interface
Service Providers
SRRP
Wholesaler Retail
VPRN VPRN
Retail
7750 VPRN
SR-7/SR-12
SRRP Backup State
OSSG127
9.3.20.8.3 Synchronization
If dual homing is used with regular interfaces that run IGMP the nodes must be
configured to synchronize the Layer 3 IGMP state.
The service IDs for both the wholesale VPRN and the retailer VPRN must be the
same in both nodes.
Multi-Chassis Redundancy for a retail service is enabled with the SRRP and
redundant interface configuration on the wholesale group interface parented by the
forwarding subscriber interface. The multi-chassis state (active or standby) of the
retail subscriber host is determined from the SRRP state (master/non-master) of the
group interface that parents the SAP of the retail subscriber host. The retail service
id must be equal on both nodes.
exit
group-interface "group-int-1-2" create
dhcp
--- snip ---
exit
redundant-interface "red-int-1"
sap 1/1/6:2.4001 create
description "SRRP 2 message path"
exit
srrp 2 create
message-path 1/1/6:2.4001
priority 50
send-fib-population-packets outer-tag-only
no shutdown
exit
pppoe
--- snip ---
exit
exit
exit
no shutdown
exit
Retail unnumbered host routes must be leaked in the wholesale service. Retail
subscriber subnets and prefixes leaked in the wholesale service are needed to
forward downstream shunted traffic over the redundant interface.
• The address of an IPv6 unnumbered subscriber host (enabled with ipv6 allow-
unmatching-prefixes on the retail subscriber interface) is not contained in the
IPv6 prefixes configured on the retail subscriber interface. IPv6 retail subscriber
host routes are automatically exported to the wholesale service.
Multi-chassis redundancy is supported for IPoE (IPv4 and IPv6) and PPPoE (IPv4
and IPv6) retail subscriber hosts and sessions.
The service ID of each retailer service is synchronized over MCS. Therefore, service
IDs for the retailer VPRN must be the same in both nodes.
To take full advantage of SRRP resiliency and diagnostic capabilities, the SRRP
instance is tied to a MCS peering that terminates on the redundant node. Once the
peering is associated with the SRRP instance, MCS synchronizes the local
information about the SRRP instance with the neighbor router. MCS automatically
derives the MCS key for the SRRP instance based on the SRRP instance ID. An
SRRP instance ID of 1 would appear in the MCS peering database with a MCS-key
srrp-0000000001.
The SRRP instance information stored and sent to the neighbor router contains the
following:
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.
Redundant BNG nodes are not always collocated. This means that the logical link
associated with the redundant (shunt) interfaces is taking the uplink path thus
wasting valuable bandwidth (downstream traffic that arrives to the standby (SRRP
backup state) node is routed by uplinks for the second time over to the active (SRRP
master state) node).
To meet the requirement to reduce the existence of shunted traffic only to the short
transitioning period between SRRP switchovers while the routing on the network side
is converging, the following was required (referring to Figure 111):
1. Share IP subnets over multiple SRRP instances. This is not mandatory, but it
would help to load balance traffic over the two nodes. For example, IP subnets
10 and 11 can be shared over SRRP instances 10 and 20 on node 1, and the IP
subnet 12 can be associated with the SRRP instance 30 on node 2.
2. SRRP aware routing – this allows to dynamically increase routing metric on the
IP subnets advertised from the Master SRRP node in comparison to the Standby
SRRP node. It also allows to advertise and withdraw routes from a routing
protocol based on the SRRP state. In this way, downstream traffic is routed in a
predictable manner towards the active node (SRRP master state).
3. SRRP Fate Sharing for SRRP instances 10 and 11. This ensures congruency of
SRRP states on the same node. This is a necessary step towards SRRP aware
routing.
10. 0.0.0 24 W
11. .0.0/
STBY
12.
0.0 /24
IGPvertiz
0
.0/2 Wi h Hig
Ad
grp-if 3
4 W th L her
/BG
SRRP 30
P
it
Hig r P f
e
ACT
her ref
Pre
CPEs
f
Access
Node
Redundant CORE
VPLS SRRP
Interface
Lo wer Pref
BNG 2
r P ef
rtiz P
ref
we Pr
grp-if 1
Wi h Lo her
e
SubIntf IP@
Ad P/BG
CPEs
ith
IG
11.0.0.1/24
.0. 0/2 W
th
Node
0
10 .0.0.
grp-if 2
11
.
SRRP 20 +
No Traffic
ACT Over the
Redundant
Interface
grp-if 3
–
SRRP 30
Multiple Routes
Per Pair
STBY
Traffic Flow of BNGs
Manual Routing
Traffic Flow
Policy Creation
After a Fallover
al_0051
SRRP Fate Sharing is a concept in which a group of SRRP instances track a single
operational-object comprised of SRRP messaging SAPs. The SRRP instances
behave as one (in the single failure case) with regards to SRRP 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 Figure 112. SRRP Fate Sharing provides optimal protection in the context
of a single failure in the network.
BNG 1 BNG 1
Active Standby
Master Init
Master Backup
Master Backup
Master Backup
Fallover
Single Failure
BNG 2 BNG 2
Standby Active
Backup Master
Backup Master
Backup Master
Backup Master
al_0052
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.
BNG 2
Master
Init
Master
Master
al_0053
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 since they can be tied into Eth-OAM.
When there are simultaneous multiple failures (multiple ports fail at the same time),
it is possible that the SRRP instances within the FSG settle in any of the three
possible SRRP states: Master, Backup, or Init. In such scenario, shunted traffic
ensues.
In the premise of SRRP Fate Sharing, the network failure is reflected in the
operational state of the messaging SAP over which SRRP runs. This is the case if
the failure is localized to the BNG (somewhere on the directly connected link). In the
case of non-localized failure (beyond the direct reach of the BNG node), Eth-OAM
might be needed in to detect the remote end failure and consequently bring the SAP
operationally into a DOWN state.
Once the single network failure is detected, all instance within the FSG transitions
into 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.
10. 0.0.0 24 W
11. 0.0.0/
ACT
12.
0.0 /24
IGPvertiz
.0/2 Wi th Low
Ad
4 W th L
grp-if 3
/BG
SRRP 30
P
P3
Hig r P
e
STBY
her ref
e
Pre
CPEs
f
Access
Node
Redundant CORE
VPLS SRRP
Interface
Hig er Pref
BNG 2
rP f
he Pre
rtiz P
ref
e
grp-if 1 SubIntf IP@
Wi th L ower
Ad P/BG
th ow
SRRP 10 10.0.0.1/24
L
ve
CPEs
ith
IG
11.0.0.1/24
W
/24 Wi
Access STBY
12 0.0 /24
12.0.0.1/24
0.0 24
Node P1
0
.0. .0/
10 .0.0.
grp-if 2
11
.
SRRP 20
STBY
P2
grp-if 3
SRRP 30
ACT
Traffic Flow P3
Traffic Flow
After a Fallover
al_0054
SRRP 1
AN 2 BNG 2
SRRP 2
al_0055
SRRP 1
2
AN 2 BNG 2
SRRP 2
al_0056
SRRP 1
STP
AN 2 BNG 2
SRRP 1'
SRRP 2
al_0057
SRRP 1
AN 2 BNG 2
SRRP 2
al_0058
Fate Sharing Group (FSG) is relaying on tracking the state of messaging SAPs over
which SRRP instances run. An SRRP instance with the messaging SAP
operationally DOWN transitions into the Init state.
The transitioning of any messaging SAP in a FSG into an UP/DOWN state triggers
SRRP priority adjustment within the FSG. The SRRP priorities should be chosen
carefully to achieve the desired behavior. They are modified dynamically as the SAP
states change. The range in which SRRP priorities can be modified is from 1 to the
SRRP priority that is initially configured under the SRRP node. Here are some
general guidelines for choosing SRRP priorities in a FSG:
• 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 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:
BNG 1 boots up and all messaging SAPs transition into the UP state. When the first
SRRP instance in FSG-1 comes up, it looks under the FSG to finds out how many
messaging SAPs are operationally UP. Since all messaging SAPs are operationally
UP, this first SRRP instance assumes its initially configured priority of 100. The other
two SRRP instances in the same FSG follows the same sequence of events.
BNG 2 follows the same flow of events. As a result, all SRRP instances within the
corresponding FSG are in the SRRP master state on BNG 1.
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.
To introduce minimal network disruption, first create messaging SAPs in both BNG
nodes and ensure that both SAPs are operationally UP. Then a new SRRP 4
instance should be created on both BNG nodes. The next step would be to include
this new messaging SAP into a SAP monitoring group. And finally, the SRRP-4 is
added into the FSG (1 and 2). This triggers the recalculation of SRRP priorities for
the existing FSG-1 and FSG-2. Since all SRRP priorities are at the max (initially
configured priority), nothing changes.
There are more disruptive ways of adding an SRRP instance into a FSG. One such
example would be in the case where SRRP priorities are not at their maximum
(initially configured) priority. If an SRRP instance is first added into an FSG that is in
a backup state, this would increase the FSG priority and potentially cause a
switchover. If the SRRP instances is then added in a FSG on the peer BNG
(previously 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, once 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
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:
There are three cases that need to be covered, each case with its own specifics:
Depending on the route type, the action is to either modify the route metric based on
the SRRP state that the route is tracking, or to advertise/withdraw the route based
on the SRRP state that the route is tracking. The action is defined in the routing policy
and it is based on the new attributes with which the routes are associated.
To achieve a better granularity of the routes that are advertised, an origin attribute is
added to the subscriber management routes (/32 IPv4 routes and IPv6 PD wan-host)
with three possible values:
aaa
IPv4
IPv6
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
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.
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.
The downside of this static approach is that during the port or card failure and
consequently a SRRP switchover, the node with the failed port or card continues to
advertise routes with the same high metric if the subscriber interface is in the ‘UP’
state (or a single SAP under it). That is, the network side is not aware of the
switchover. It continues to forward traffic to the standby node, and as a result, heavy
shunt traffic ensues. To effectively deal with this, the network side must be aware of
the routing change that occurred in the access layer.
When failure is detected, the metric for the route is changed automatically based on
the following configuration:
configure
service <type> <id>
subscriber-interface <ip-int-name>
address <ip-address> gw-ip-address <gw-address> track-srrp <srrp-
inst> holdup-time <msec>
ipv6
subscriber-prefixes
prefix <ipv6-prefix> pd track-srrp <srrp-id> holdup-time <msec>
prefix <ipv6-prefix> wan-host track-srrp <srrp-id> holdup-
time <msec>
policy-options
begin
policy-statement <name>
entry 1
from
protocol direct
state ‘srrp-master’
exit
action accept
metric set 100
exit
exit
entry 2
from
protocol direct
state ‘srrp-non-master’
exit
action accept
metric subtract 10
exit
exit
entry 3
from
protocol direct
exit
action accept
exit
exit
This configuration ensures that the route metric is changed for the subscriber
interface routes based on the SRRP state while the other, non-subscriber directly
attached routes are unaffected by SRRP.
The routing policy also provides the flexibility to prevent route advertisement (action
reject) instead of changing the route metric.
Although this feature is designed to minimize or eliminate the use of the redundant-
interface, it is important to note that the redundant-interfaces are still used in the case
of transient conditions. An example of such condition would be:
Only the state attribute is applicable to managed routes, and only to the ones that are
synchronized (static and RADIUS obtained – framed-route and framed-ipv6-route).
The managed routes obtained by BGP are not synchronized and this feature is not
applicable to them.
Based on the SRRP state, the managed route can be either advertised with a
modified metric or be withdrawn altogether.
For example:
Managed routes that are tracking SRRP state are only advertised from the active
node (SRRP master state) and denied from standby node (SRRP backup state). All
other managed routes that are not tracking SRRP state are advertised regardless of
the SRRP state.
policy-options
begin
policy-statement <name>
entry 1
from
protocol managed
state ‘srrp-master’
exit
action accept
exit
exit
entry 2
from
protocol managed
state ‘srrp-non-master’
exit
action reject
exit
exit
entry 3
from
protocol managed
exit
action accept
exit
exit
Both attributes (state and origin) are applicable to the subscriber management
routes.
For Example:
policy-options
begin
policy-statement <name>
entry 1
from
origin dynamic
state ‘srrp-master’
exit
action accept
exit
exit
exit
entry 2
from
origin dynamic
state ‘srrp-master’
exit
action accept
exit
exit
subscriber-interface <ip-int-name>
address <ip-address> gw-ip-address <gw-address> track-srrp <inst-name> holdup-
time <msec>
ipv6
subscriber-prefixes
prefix <ipv6-prefix> pd track-srrp <srrp-id> holdup-time <msec>
prefix <ipv6-prefix> wan-host track-srrp <srrp-id> holdup-time <msec>
For managed and subscriber management routes, this is explicitly enabled under the
group interface:
group-interface <ip-int-name>
srrp-enabled-routing holdup-time <msec>
In certain 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 multi-homed 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 towards the Standby PW,
effectively being black-holed.
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.
Metric adjustment for the subscriber routes is supported. Once 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.
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]
• 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>
A hold timer is provided within the oper-group command to suppress flapping of the
monitored object (SAP or pseudowire).
Figure 119 shows an example with ESM over pseudowire through a VSM loop.
al_0059
*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
===============================================================================
>config>subscr-mgmt>diam-appl-plcy>gx>3gpp-qos-mapping>
Subscriber QoS overrides can also be activated using subscriber services. See QoS
Override-Based Subscriber Service for details.
The format of QoS Overrides AVP's in the 3GPP-1016 QoS-Information AVP are
described in the 7750 SR Gx AVPs Reference Guide.
The operational value of some of the QoS parameters can be derived from different
sources.
For queue and policer QoS parameters, the following hierarchy applies (highest
priority is listed first):
• ANCP overrides
• Subscriber Services QoS overrides
• Subscriber QoS overrides (RADIUS, DIAMETER)
• Overrides configured at sub-profile level
• Scheduler/arbiter parameters as configured in scheduling/policer-control-policy
Up to 18 QoS overrides can be installed per subscriber host or session. A new set of
QoS overrides received using a mid-session change replaces the previous set of
QoS overrides.
QoS overrides are always stored as part of the subscriber host or session data but
are only applied when the override is valid in the active QoS configuration. For
example:
• An egress queue 5 PIR rate override is stored with the subscriber session but
not applied when the sap-egress QoS policy has no queue 5 defined
The active QoS overrides per-subscriber and per-SLA Profile Instance can be
displayed with:
The number of allocated and free Subscriber SLA Profile Instance QoS overrides,
QoS Intermediate Arbiter Overrides and QoS User Scheduler Overrides per-line card
can be monitored with the tools dump resource-usage card CLI command.
DS-Lite is an IPv6 transition technique that allows tunneling of IPv4 traffic across an
IPv6-only network. Dual-stack IPv6 transition strategies allow service providers to
offer IPv4 and IPv6 services and save on OPEX by allowing the use of a single IPv6
access network instead of running concurrent IPv6 and IPv4 access networks. DS-
Lite has two components: the client in the customer network, known as the Basic
Bridging BroadBand element (B4) and an Address Family Transition Router (AFTR)
deployed in the service provider network.
DS-Lite leverages a network address and port translation (NAPT) function in the
service-provider AFTR element to translate traffic tunneled from the private
addresses in the home network into public addresses maintained by the service
provider. On the 7750 SR, this is facilitated through the Carrier Grade NAT function.
Software
IPv4 Home Network
IPv4
Internet
IPv4 Home Network
Software Server
Concentrator
IPv6 + NAT
IPv4 Home Network Access
Network
Stateful
al_0060
As shown in Figure 120, DS-Lite has two components, a softwire initiator in the RG
and a softwire concentrator, deployed in the service provider network, where control-
less IP-in-IP (using protocol 4 - IPv4 in IPv6) is used for tunneling. When using
control-less protocol, packets are sent on the wire for the remote softwire endpoint
without prior setup of a tunnel.
The softwire initiator in the home network is combined with a routing function, where
the default route is passed to the softwire pseudo-interface. Note that there is no NAT
function, therefor, the private IP addresses of the home network are encapsulated
without source address modification, and forwarded to the softwire concentrator
where all NAT is performed. The softwire pseudo-interface unicasts all IPv4 traffic to
the IPv6 address of the softwire concentrator, which was pre-configured.
When encapsulated traffic reaches the softwire concentrator, the device treats the
source-IP of the tunnel to represent a unique subscriber. The softwire concentrator
performs IPv4 network address and port translation on the embedded packet by re-
using Large Scale NAT and L2-Aware NAT concepts.
9.3.23.1 IP-in-IP
As shown in Figure 121, 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.
IPv6
User Session Internet
IETF Software
IPv6 IPinIP
Dual Stack
Home Network
Dual Stack IPv4
Lite Router Internet
IPv6-only 7750
BNG BNG
NAT Function
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 given the heavy use of RFC 1918
address space.
The lack of control of protocol for the IP-in-IP tunnels simplifies the functional model,
since any received IPv4 packet to the ISA DS-Lite address can simply be:
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.
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 L2-
Aware NAT feature as shown in Figure 122.
As ESM is used, scale is limited by the number of ESM hosts supported on a chassis
and any associated resources like queues.
IPv6
Home Network IPv4 Internet IPv6
Internet
L2TP Tunnel
DSL
Softwire Router
Client Software
(Existing) Concentrator
(LNS)
al_0062
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 L2-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.
Call trace also logs some events that are not directly associated to a protocol, such
as LUDB access.
Call trace can present the captured packets for further processing in one of the
following ways:
• Call trace can send the captured packets as live output over a UDP tunnel to an
external monitoring device.
• Call trace can store the captured packets as PCAP on a pre-provisioned
compact flash. If the system already uses the compact flash intensively, such as
for ESM persistency, then this method is not recommended for use in a live
network.
• Call trace can display decoded packets in debug output. This method is mainly
for use in low-scale debugging of a few sessions; use on large-scale live
networks may impact overall performance.
Generated traces contain the original packets, encapsulated in a custom header that
contains metadata. To decode the metadata and extract the packet, a Nokia-specific
Wireshark plug-in is required. Contact the Nokia Technical Assistance Center (TAC)
for information.
In general, call trace does not include packets that are common between sessions.
Where it is necessary to indicate failure or progress, an event is generated. This is
done to guarantee consistency between session traces, independent of timing or
session setup order. For example, for PPPoE LAC sessions, L2TP tunnel setup
messages are not reflected in call trace, but an event is generated to indicate
whether an L2TP tunnel was set up successfully. Subsequent L2TP session setup
messages are traced in context of the PPPoE LAC session.
When storing call trace results on a compact flash, files are not automatically
synchronized to the standby CPM.
Call trace distinguishes between traces and trace jobs. A trace consists of a set of
matching criteria and additional parameters such as a trace profile and a name. Each
session that matches a trace creates a trace job if system resources are available.
Trace jobs can either be stopped individually or by removing the original trace. By
default, existing sessions do not create a trace job when a new trace is enabled; this
functionality must be explicitly enabled.
Similar, a NetBIOS Name Service (NBNS) provides services to register and lookup
computer names on a network that uses NetBIOS as a naming service. NBNS name
resolution is IPv4 only. An NBNS name server answers NBNS queries from clients
such as subscriber sessions. The NBNS name server address is always an IPv4
address and must be provisioned in the client.
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 Table 28. 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 Figure 123.
Notes:
2 2 2
2 2 2
1 5 Default relative priority when DNS and NBNS Name Servers are obtained from multiple authentication origins
sw1152
For redundancy purposes multiple name servers can be associated with a subscriber
session:
The order of preference in which the name servers are sent to the client is:
1. Primary
2. Secondary
3. Extended
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):
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)
Note: Extended DNS name servers are handled as a set: they should come from the same
authentication origin (only DHCP in current release) and all extended DNS name servers
are updated when changed mid-session.
After authentication of the first host of a subscriber session, primary, secondary, and
extended DNSv4 and DNSv6 name servers and primary and secondary NBNS name
servers of the highest authentication origin priority are associated with the subscriber
session. The name servers of the authenticating host's IP stack are sent to the client.
The same happens when a new host is associated with an existing session and re-
authentication is performed.
• for authenticated renewals of IPoE DHCP hosts, such as a DHCP host renewal
of an IPoE session for which the configured minimum authentication interval has
expired — primary, secondary, and extended DNSv4 and DNSv6 name servers
and primary and secondary NBNS name servers of the highest authentication
origin priority are associated with the subscriber session. The name servers of
the authenticating host's IP stack are sent to the client.
• for unauthenticated renewals of IPoE DHCP hosts and PPPoE DHCPv6 hosts
— if the name servers of the renewing host's IP stack that are associated with
the session were obtained from DHCP or defaults, the name servers committed
by the DHCP server (or the defaults) are sent to the client. Otherwise, the name
servers of the renewing host's IP stack that are associated with the session are
sent to the client.
• for RADIUS CoA — the name servers received in a CoA are immediately
associated with the subscriber session and sent to the client at the next
unauthenticated DHCP renewal. For SLAAC hosts, an unsolicited Router
Advertisement is sent if the DNSv6 name server addresses in the CoA are
different from those stored in the session.
When updating DNS or NBNS name servers with a CoA, it is important to also
update all authentication sources such that when the subscriber session re-
authenticates, the correct name servers are assigned. For example:
9.3.25.3.3 Verifying the DNS and NBNS Name Servers Stored for a Subscriber
Session
The following show commands are used to verify the DNS and NBNS name servers
stored for a subscriber session:
In the following sample example only DNS and NBNS name servers output is shown:
IPv4 NBNS Primary : N/A
IPv4 NBNS Secondary : N/A
IPv4 DNS Primary : 10.1.2.1
IPv4 DNS Secondary : 10.1.2.2
IPv4 DNS Extended 1 : 10.1.4.3
IPv4 DNS Extended 2 : 10.1.4.4
IPv6 DNS Primary : 2001:db8:dddd::3:1
IPv6 DNS Secondary : 2001:db8:dddd::3:2
IPv6 DNS Extended 1 : 2001:db8:dddd::4:3
IPv6 DNS Extended 2 : 2001:db8:dddd::4:4
The Primary and Secondary DNS and NBNS fields are always shown. When no IP
address is available, they are shown as N/A (Not Applicable). The Extended DNS
fields are only present when the corresponding name server IP addresses are stored
in the session state.
In exceptional cases, the DNS name servers stored for a subscriber session do not
match the DNS name servers sent to the client. For example, when the DNS name
servers were not requested in an Option Request Option (6) for a DHCPv6 host, the
DNS name servers are stored in the subscriber session but not sent to the client.
IPoE DHCPv4
A group interface configured as DHCPv6 Relay or DHCPv6 Proxy only inserts a DNS
Recursive Name Server Option (23) in the DHCP Advertise and DHCP Reply
message when requested by the DHCPv6 client in the Option Request Option (6)
and at least one DNS name server IP address is received during authentication.
An SR OS DHCPv6 server (DHCPv6 relay) and a DHCPv6 proxy server insert the
DNS Recursive Name Server Option as a global DHCPv6 option.
PPPoE IPCP
A PPPoE client obtains DNS and NBNS name servers by including following
configuration options in its IPCP Configure Request:
Note: A PPPoE DHCPv4 client does not include a Parameter Request List Option (55) in
its DHCP messages. The Domain Name Server Option (6), the NetBIOS Name Server
Option (44), or both that is returned by the DHCP server are evaluated according the
authentication origin priority to determine the DNS and NBNS name server IP address
assigned to the PPPoE session.
Mid-session changes are not supported for PPPoE DNSv4 and NBNS name server
updates.
There are two mechanisms to assign a DNSv6 name server to an IPv6 SLAAC hosts:
• Stateless DHCPv6
The client starts a stateless DHCPv6 transaction by sending an Information
Request message.
- PPPoE session
An Information Request message is always authenticated:
• When no DNSv6 name servers are received during authentication,
then DHCPv6 relay is performed irrespective of whether the DNSv6
name servers are associated with the PPP session or not. The DNSv6
name servers in the Reply message from the DHCP server (or defaults
if not available from DHCP) are sent to the client. These DNSv6 name
servers are not associated with the PPP session.
• When DNSv6 name servers are received during authentication,
DHCPv6 proxy is performed and the DNSv6 name servers are included
in a DNS Recursive Name Server Option (23) of the Reply message
sent on behalf of a DHCPv6 server. The DNSv6 name servers are not
associated with the PPP session.
Since the Information Request for PPP SLAAC hosts are always
authenticated, a mid-session change of DNSv6 name servers using CoA is
not supported. Instead, the DNSv6 name servers can be included in the
RADIUS Access Accept message.
- IPoE session
config>service>ies>sub-if>grp-if>ipv6>rtr-adv
config>service>vprn>sub-if>grp-if>ipv6>rtr-adv
config>subscr-mgmt>rtr-adv-plcy
dns-options
[no] include-dns - Set/reset inclusion of the RDNSS server
option 25 on this group-interface
[no] rdnss-lifetime - Maximum time the RDNSS address is valid
in this group-interface
IPoE Sessions
As a result of the single authentication for dual stack IPoE sessions, DNS and NBNS
name servers for both IPv4 and IPv6 should be provided irrespective of the IP stack
that triggers the authentication or re-authentication.
SR OS DHCP Server
An SR OS DHCPv4 server does not check the Parameter Request List Option (55)
and always includes the configured options for the matched pool. Likewise, an SR
OS DHCPv6 server does not check the Option Request Option (6) and always
includes the configured options for the matched pool.
Table 28 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.
DHCP options can be specified in RADIUS or Local User Database (LUDB) and then
appended to the options present in DHCP messages to the client:
When a DHCPv4 Domain Name Server Option (6), a DHCPv4 NetBIOS Name
Server Option (44), or a DHCPv6 DNS Recursive Name Server option (23) is
included using the described To Client Options methods, these options are
appended in the outgoing DHCP message to the client, irrespective of whether
DNS or NBNS options were already present. The name servers included in the
DHCP options with the To Client Options method are not associated with the
subscriber session as primary, secondary, or extended DNS servers.
The DHCPv4 and DHCPv6 Python API enables the manipulation of DHCP packets
received from or sent to the client.
Inserting a DHCPv4 Domain Name Server Option (6) or NetBIOS Name Server
Option (44) in the DHCPv4 Offer and Ack messages using the alc.dhcpv4.set()
Python API or inserting a DHCPv6 DNS Recursive Name Server option (23) in the
DHCPv6 Advertise and Reply messages using alc.dhcpv6.set() Python API
overwrites the corresponding option in the message sent to the client. In this case,
the name servers associated with the subscriber 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 prior to 21.7 can be enabled using the following
configuration:
configure subscriber-mgmt
system-behavior
legacy-dns-nbns
Figure 124 Legacy DNS and NBNS Name Server Authentication Origins
LUDB LUDB LUDB
2 2 2
5 1 1 1
1 5 Default relative priority when DNS and NBNS Name Servers are obtained from multiple authentication origins (legacy-dns-nbns)
sw1153
• supported authentication origins and their relative priorities for DNS and NBNS
name servers as illustrated in Figure 124:
- 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
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.
Note: The legacy system behavior for DNS and NBNS name servers is available as a
temporary workaround. The recommended configuration is the default extended DNS and
NBNS name server origin priorities (no legacy-dns-nbns).
- Acct-Tunnel-Connection
- Acct-Tunnel-Packets-Lost
Tunnel level accounting and session level accounting can be enabled or disabled
independently.
New accounting packets and related RADIUS attribute list are described in Table 29.
Tunnel-Type:0 —
Tunnel-Medium-Type:0 —
Tunnel-Assignment-Id:0 —
Tunnel-Client-Endpoint:0 —
Tunnel-Client-Auth-Id:0 —
Tunnel-Server-Endpoint:0 —
Tunnel-Server-Auth-Id:0 —
Tunnel-Type:0 —
Tunnel-Medium-Type:0 —
Tunnel-Assignment-Id:0 —
Tunnel-Client-Endpoint:0 —
Tunnel-Client-Auth-Id:0 —
Tunnel-Server-Endpoint:0 —
Acct-Terminate-Cause —
Tunnel-Type:0 —
Tunnel-Medium-Type:0 —
Tunnel-Assignment-Id:0 —
Tunnel-Client-Endpoint:0 —
Tunnel-Client-Auth-Id:0 —
Tunnel-Server-Endpoint:0 —
Tunnel-Server-Auth-Id:0 —
Acct-Session-Time —
Acct-Input-Gigawords —
Acct-Input-Octets —
Acct-Output-Gigawords —
Acct-Output-Octets —
Acct-Input-Packets —
Acct-Output-Packets —
Acct-Terminate-Cause —
Event-Timestamp —
Service-Type Framed
Class —
Tunnel-Type:0 —
Tunnel-Medium-Type:0 —
Tunnel-Assignment-Id:0 —
Tunnel-Client-Endpoint:0 —
Tunnel-Client-Auth-Id:0 —
Tunnel-Server-Endpoint:0 —
Tunnel-Server-Auth-Id:0 —
Tunnel-Medium-Type:0 —
Tunnel-Assignment-Id:0 —
Tunnel-Client-Endpoint:0 —
Tunnel-Client-Auth-Id:0 —
Tunnel-Server-Endpoint:0 —
Acct-Terminate-Cause —
Acct-Tunnel-Connection —
Event-Timestamp —
Service-Type Framed
Class —
Tunnel-Type:0 —
Tunnel-Medium-Type:0 —
Tunnel-Assignment-Id:0 —
Tunnel-Client-Endpoint:0 —
Tunnel-Client-Auth-Id:0 —
Tunnel-Server-Endpoint:0 —
Tunnel-Server-Auth-Id:0 —
Acct-Tunnel-Connection —
Acct-Session-Time —
Acct-Input-Gigawords —
Acct-Input-Octets —
Acct-Output-Gigawords —
Acct-Output-Octets —
Acct-Input-Packets —
Acct-Output-Packets —
Acct-Tunnel-Packets-Lost —
Acct-Terminate-Cause —
Notes:
• Errors occur if there are multiple hosts sharing the same sla-profile instance and
then these hosts go to different tunnel.
• 7750 SRs have an internal limitation of 500 pps for accounting messages. This
feature shares the same limitation.
Attribute Tunnel/Link
nas-identifier Both
Alc-Tunnel-Acct-Policy String Policy-name; if the name is disable then this means L2TP
tunnel accounting is disabled for this tunnel
The Alc-Tunnel-Acct-Policy takes precedence over what is defined in CLI when Alc-
Tunnel-Group is also returned.
The route download process requests the routes to a configured RADIUS server by
triggering an access-request message. The key identifier for this message is the
username, which is a combination of the system’s name (or an optionally configured
value), appended by a dash ( “-”) and then a monotonically increasing integer. The
download process sends an access request starting with 1 (such as “hostname-1”)
and the RADIUS server replies with an access-accept message and a number of
routes embedded within the message. The system then increases the counter and
sends another access request (this time being hostname-2) and receive a reply with
the next batch of routes to download. The process continues, incrementing the
counter by 1 each time until the system gets an access-reject or the maximum
number of routes that can be downloaded is reached.
The prefix-mask could be in any form as ‘prefix/length’, ‘prefix mask’ or ‘prefix’ (in the
latter case, for IPv4 routes, the mask shall be derived from the IP class of the prefix).
IPv6 routes are also supported. The format is based on using the IETF-defined IPv6
Framed-IPv6-Route (attribute 99). The following text shows the supported formats.
All the routes downloaded are a new protocol type “periodic”. The download process
re-starts the AAA requests after a given interval (a configurable value but target
refresh rate is 15 minutes) and routes shall be updated according to the following
process:
• When the router initiates a new download process, the routes are kept in a
temporary table until the download process completes (receives an access-
reject from the AAA). The temporary download table is then checked for errors
and finally, any changes reflected to the actual routing table.
• Routes no longer present in the download are removed from the routing table.
• If the AAA server responds with an access-reject for the first username (that is,
an implicit empty route-download table), all routes are removed from the routing
table.
• If there are any protocol errors (at the RADIUS level), such as time-out, no
response, bad record format, too many records, and so on, the download
process is suspended and retried after a configurable timer. The minimum retry
timer is at least 1 minute and given the light load this represents control-plane-
wise (concurrent downloads are not supported) the retries can continue infinitely
until the next refresh period occurs, where the download restarts from the
beginning. An exponential backoff algorithm with a configured minimum and
maximum delay is used to determine the retry timer.
• The routes are only purged from the routing table after a complete download
process was achieved (properly terminated with an access-reject message).
Under any other failure condition, the routes shall remain active. Shutting down
the download process should not remove the downloaded routes. A clear
command clears the periodic routes.
• All the imported routes (blackholes) are imported into the line-card FIBs to avoid
the routing loops caused by announcing the prefixes but not installing the actual
blackholes.
IES
MSAP subscriber-
interface
RADIUS
group-interface
MSAP group-interface
MSAP VPRN
subscriber-
group-interface interface
MSAP
group-interface
2. Authentication
VPLS
Capture
SAP
1. Subscriber connects: trigger
packet received on capture SAP
7750 SR-BNG
sw2005
Multiple trigger types can be enabled on a single capture SAP. The data and arp
trigger types are mutually exclusive.
A SAP lookup based on the outer and inner tags is performed when a packet is
received on a port. When no corresponding SAP or MSAP is found, the packet is
handled by the capture SAP, meaning that the trigger packets are sent to the CPM
and all other packets are dropped.
An ingress VLAN ID (VID) type mac filter can be configured on a capture SAP to have
additional control on the VLANs that are allowed to initiate a host setup. Other filter
types are not supported on a capture SAP.
• <port-id>:* — Matches any valid single tagged trigger packet on a <port-id> for
which no more specific SAP or MSAP is found.
A single q-tag (<port-id>:tag) is available for authentication. The corresponding
MSAP is created as: <port-id>:tag
- It is not possible to create a y.* network interface when there is a *.x capture
SAP present on the port (y=0,1..4094,* and x=1..4094).
- There is no support for single-tagged MSAP creation.
config service
vpls 10 customer 1 create
sap 1/1/1:*.* capture-sap create
allow-dot1q-msaps
config system
ethernet
new-qinq-untagged-sap
config subscriber-mgmt
local-user-db "ludb-1" create
ipoe
host "single-tagged" create
host-identification
encap-tag-range start-tag *.0 end-tag *.0
exit
msap-defaults # defaults for dot1q MSAPs
group-interface "group-int-2"
policy "msap-policy-2"
service 2000
exit
no shutdown
exit
exit
config service
vpls 10 customer 1 create
sap 1/1/1:*.* capture-sap create
trigger-packet dhcp dhcp6
allow-dot1q-msaps
ipoe-session
ipoe-session-policy "ipoe-policy-1"
user-db "ludb-1"
no shutdown
exit
msap-defaults # defaults for qinq MSAPs
group-interface "group-int-1"
policy "msap-policy-1"
service 1000
exit
exit
MSAP parameters can be obtained from multiple sources with the following order of
preference:
The local user database should be configured at the capture SAP and group
interface context. For example:
• IPoE sessions:
config>service>vpls>sap# ipoe-session user-db local-user-db-name
config>service>ies>sub-if>grp-if# ipoe-session user-db local-user-db-
name
• PPPoE sessions:
config>service>vpls>sap# pppoe-user-db local-user-db-name
config>service>ies>sub-if>grp-if>pppoe# user-db local-user-db-name
• IPoE sessions
config>subscr-mgmt>loc-user-db>ipoe>host# auth-policy policy-name
or
config>subscr-mgmt>loc-user-db>ipoe>host# diameter-auth-policy
policy-name
• PPP sessions
config>subscr-mgmt>loc-user-db>ppp>host# auth-policy policy-name
or
config>subscr-mgmt>loc-user-db>ppp>host# diameter-auth-policy policy-
name
The MSAP parameters are configured at the local user database host context. For
example:
config>subscr-mgmt>loc-user-db>ipoe>host# msap-defaults
config>subscr-mgmt>loc-user-db>ppp>host# msap-defaults
- msap-defaults
The MSAP is not created if the group interface name returned from RADIUS or
DIAMETER has a different authentication policy than the authentication policy
configured at the capture SAP.
Table 32 lists the RADIUS attributes (VSAs) and DIAMETER AVPs required to
obtain MSAP parameters in the authentication phase.
Alc-MSAP-Policy [26-6527-32] String The name of the policy that defines the
MSAP parameters.
MSAP parameters that are not obtained from a local user database lookup, and that
are not returned from RADIUS or DIAMETER can be specified in the msap-defaults
section of the capture SAP context (this is a last resort scenario):
config>service>vpls>sap# msap-defaults ?
- msap-defaults
[no] group-interface - Configure the group interface
[no] policy - Configure the MSAP policy
[no] service - Configure the service
If local user database, RADIUS, or DIAMETER authentication did not provide all the
required information to create the subscriber host or session (no IP address for
example), then the MSAP is created with a short timer while waiting for the host to
acquire the missing information. If no host is instantiated when the timer expires, the
MSAP is deleted.
Multiple subscribers, subscriber hosts or sessions can share a single MSAP. The
MSAP is created with the first instantiated subscriber host or session and deleted
when the last associated subscriber host or session is removed from the system.
Note that only a single MSAP policy can be specified for a given MSAP. An attempt
to change the MSAP policy by a new subscriber host or session for an existing MSAP
results in a host or session setup failure.
These MSAP queues have limited use and can be suppressed in most cases. For
single-subscriber MSAPs, the MSAP queues can be suppressed with the sub-sla-
mgmt single-sub-parameters profiled-traffic-only CLI command.
The default QoS policy associated with MSAPs may need to be changed to
accommodate different scenarios. For example:
Egress multicast traffic in per MSAP replication mode is forwarded by the MSAP
queues or policers. Multicast traffic can be mapped into a dedicated queue or
policer. The MSAP queue can be port-parented to provide scheduling priority on
the port level.
The QoS policies associated with an MSAP are configured in the MSAP policy.
• Because the sticky MSAP is never deleted, the subscriber can start a session
faster; processing time is reduced because the MSAP does not have to be
recreated.
• The MSAP may contain valuable historical information for the service provider.
Keeping the MSAP provides a means for the service provider to look up
subscriber historical data.
The MSAP is only be eligible for stickiness if it was successfully created. The sticky
MSAP introduces a new state: idle. An idle MSAP indicates that the subscriber on
the MSAP has disconnected and the MSAP is ready for a new subscriber connection.
An example is shown below:
There are two ways to remove sticky MSAPs from the system:
Note:
• This command can remove MSAPs with active subscribers. To clear only MSAPs
without any active subscriber, use the keyword idle-only.
• Persistence restoration relies on configured msap-defaults parameters under capture
SAP (config>service>vpls>sap>msap-defaults)
With persistence enabled, it is generally recommended to avoid changing the default
once the system has created hosts with these msap-defaults values. The hosts are
not restored by the system as the msap-defaults values are no longer the same.
The Sticky MSAP feature keeps the failed MSAPs on the system and consumes
system resources. These MSAPs can be cleared with the clear>service>id service-
id>msap command.
9.7.2 DSLAM-ID
A DSLAM ID provides the system the ability to define a DSLAM-ID string provided
through the Python script, RADIUS, or local user database. If the DSLAM-ID was
provided, but the subscriber host is instantiated on a regular MDA, the DSLAM-ID is
ignored.
The ability to aggregate subscribers into DSLAMs for the purpose of QoS, can use
the SAP ID to identify subscribers and associated DSLAMs.
9.8 Default-Subscriber
This feature provides a default subscriber definition under the SAP. If the object was
configured the operator may use ESM without enabling a processing script or a
RADIUS authentication policy. In the event both have been disabled any host that
was installed for the SAP is installed with the configured default subscriber ID. If a
RADIUS policy was used or if a script was enabled but a subscriber ID was not
returned the default subscriber ID is used.
Subscriber mirroring provides the ability to create a mirror source with subscriber
information as match criteria. Specific subscriber packets can be mirrored mirror
when using ESM with a shared SAP without prior knowledge of their IP or MAC
addresses and without concern that they may change. The subscriber mirroring
decision is more specific than a SAP. If a SAP (or port) is placed in a mirror and a
subscriber host of which a mirror was configured is mirrored on that SAP, packets
matching the subscriber host are mirrored to the subscriber mirror destination.
The mirroring configuration can be limited to specific forwarding classes used by the
subscriber. When a forwarding class (FC) map is placed on the mirror only packets
that match the specified FCs are mirrored. A subscriber can be referenced in
maximum 2 different mirror-destinations: 1 for ingress and 1 for egress.
9.11.1 Metering
Metering represents the core of time and volume-based accounting. Service usage
is typically measured by performing an accounting of the traffic passing through
corresponding subscriber-host queues (volume usage) or by keeping lease-state
while the given subscriber-host is connected to the network (time usage).
*A:ALA-48>config>subscr-mgmt# info
----------------------------------------------
...
category-map "triple-play" create
category "data" create
queue 1 ingress-egress
exit
category "video" create
queue 2 egress-only
exit
category "voice" create
queue 3 ingress-egress
exit
exit
category-map "aggr-subscriber-service" create
category "data-services" create
queue 1 ingress-egress
queue 3 egress-only
exit
exit
...
----------------------------------------------
*A:ALA-48>config>subscr-mgmt#
There can be multiple queues and/or policers aggregated into one category. There
can be up to sixteen categories in a category map.
There are two types of quota (credit), volume and time. In volume usage monitoring,
the system accumulates byte counters per category-sla-instance and compares it
with the assigned quota. Once the credit is exhausted (or threshold for renewal is
met) the system attempts to renew it with corresponding management system.
If the effective rate of the application usage does not exceed the rate defined by the
activity-threshold, the given subscriber host is considered silent and its
corresponding credit is not used. If the application usage exceeds the rate, the
application-credit is consumed (in terms of time).
The minimum credit control quota values are one second for time quota and one byte
for volume quota. These minimum values are not realistic deployment values for
multiple reasons such as effective sampling periods, statistics processing time,
RADIUS message load, subscriber scale, and so on.
The quota in the RADIUS VSA Credit-Control-Quota uses this fixed format:
Both volume and time quota should be specified in the attribute but only one credit
type (volume or time) is applied per category. The credit-type of a category is
configured in the category-map CLI context.
• Volume
• Time
Activity Threshold
Time
No quota consumption
because silence-period>Ts.
Time Quota is consumed in fixed
Quota amounts corresponding to Ts.
al_0064
To identify that the given RADIUS-auth request is related to credit renewal rather
than to plain authentication, the node includes empty credit VSAs, depending on
categories which has been exhausted. The RADIUS server can identify which
category has requested credit renewal.
• An idle-action:
- shcv-check — Perform a subscriber host connectivity check (IPoE hosts
only). Host connectivity verification should be enabled on the corresponding
group-interface for the idle-timeout-action shcv-check to take effect:
configure>service ies | vprn service-id subscriber-interface ip-int-name
>group-interface ip-int-name>host-connectivity-verify
If the SHCV check is successful, the subscriber host is not disconnected, and
the idle-timeout timer is reset to zero. If the SHCV check fails, the subscriber
host is disconnected (same as terminate).
For PPP hosts, the idle-timeout-action shcv-check is ignored and has the
same effect as idle-timeout-action terminate.
- Terminate (default): disconnect the subscriber hosts
• IPoE:
Delete the subscriber host
Send a DHCP release message to the DHCP server
Send an Accounting Stop message to the RADIUS accounting server
• PPP:
Delete the subscriber host
Send a terminate request message to the CPE
Send an Accounting Stop message to the RADIUS accounting server
Example
config>subscr-mgmt
sla-profile "sla-profile-1" create
category-map "idle-timeout"
category "cat-1" create
idle-timeout 3600
idle-timeout-action terminate
exit
exit
exit
At host instantiation, a timer is initialized to the idle-timeout value (one timer per sla-
profile instance). Each queue or policer in the category is monitored for activity over
a fixed polling interval:
When the timer becomes zero, the idle-timeout-action is performed for all hosts
associated with the SLA-profile-instance (all hosts from a subscriber on a single sap
and that share the same sla-profile).
In case of CoA, if the host’s one-time-http-filter has already been replaced then
system ignores the Alc-Onetime-Http-Redirection-Filter-Id.
The Figure 128 illustrates high level of call flow of WPP authentication.
DHCP
HTTP Request
HTTP Request
Portal Page
User Credential
WPP Request with
User Credential
Access-Request with
User Credential
Access-Accept
WPP Ack
al_0065
1. When the WLAN user starts a DHCP exchange with a 7750 SR, the router
creates a DHCP host from following configurations:
- Sub-id is the default subscriber ID configured in the sap>sub-sla-mgmt
context.
- sla-profile/sub-profile/aa-profile takes the configuration from CLI command
grp-if>wpp>initial-sla-profile/initial-sub-profile/initial-app-profile.
- IP address from local or external DHCP server is assigned to the host.
2. When the user sends an HTTP request to visit a website by browser, the router
redirects the HTTP request to the web portal.
3. The portal server sends an authentication page to the WLAN user.
4. WLAN user enters username and password in the authentication page and
submit to the portal server.
5. The portal server sends a WPP request to router together with the user
credentials.
6. The 7750 SR sends an access-request to RADIUS server with user credentials.
7. RADIUS returns an access-accept if authentication succeeds.
8. The 7750 SR returns a WPP ACK to the portal server.
9. If it was access-accept, then the router can optionally override the following host
properties:
- Sub-id: The subscriber ID from RADIUS. If there is no sub-id from RADIUS,
then the host keeps using current sub-id.
- Sla-profile, sub-profile, or aa-profile: The system uses the RADIUS server
returned values. If the RADIUS server did not return these then the system
tries to use the LUDB (in local DHCP server) return values if they are
available. If not, the system tries to use the default values configured under
SAP.
• WPP portal server — Specifies the name and IP address of the WPP portal
server.
• Enable WPP under the group-interface:
- WPP portal server that system should listen to.
- authentication-policy on group-interface that specifies address of
RADIUS server.
- def-sub-id under sap>sub-sla-mgmt that is used for DHCP host before
user is authenticated by portal server.
- initial-sla-profile and initial-sub-profile that are used for the DHCP host
before user is authenticated by portal server.
The initial-sla-profile should include a ingress filter that has http-
redirection entry.
In some cases, a 7750 SR can sit behind a Layer 3 device (such as an CMTS), where
the router does not participate in client’s DHCP process. Such a use case is different
from a normal WPP use case where the routers rely on getting client’s DHCP request
to create an initial ESM host.
This feature allows the system to create an ESM host upon successful WPP
authentication without creating an initial host.
In the above use case (behind a Layer 3 device) the user also needs to configure one
or more default hosts on the SAP to allow HTTP redirection without an ESM host.
The default-host subnet is the user’s source subnet and the next hop address is the
Layer 3 device’s interface address that connect to the SAP. Users also need to
configure the lease-populate l2-header command in the grp-if>dhcp context to
make HTTP redirection with default-host work. The grp-if>dhcp context could be
shut down in the meantime.
The SR OS supports LUDB lookup for WPP authentication. Users can optionally
configure LUDB using the grp-if>wpp context to return the WPP-related
configuration attributes (such as a portal name, initial-sla-profile, initial-sub-profile,
and so on) for an IPoE host. The system can access LUDB when creating the initial
host before WPP authentication. The LUDB returned attribute overrides the
corresponding configuration under the group-interface context.
If the WPP LUDB lookup returns an authentication policy, it is used for WPP RADIUS
authentication. When WPP LUDB is configured, the authentication policy on group-
interface is optional and only used by the WPP if there is no authentication policy
returned from the WPP LUDB lookup.
• Create a loopback interface on both 7750 SRs with the same IP address X.
• Use the track-srrp parameter while configuring address X to track the
corresponding SRRP instance.
• Configure a portal with the same name and same service-id on both nodes to
send WPP packets to the destination address.
• Use an route-policy to export X to the routing protocol. The metric the route X
can be set is based on the specified SRRP state (master or non-master) so that
the active node can advertise route X with a better metric. Then the WPP packet
from the portal is attracted to the active node.
• Only the active node process WPP packet, however in case of standby node
receives (such as routing is still re-converging) the WPP packet, then the
standby shunts the WPP back to the active node (SRRP master state).
• WPP hosts are synced by MCS.
A WPP portal group allows users to configure up to eight WPP portals in a portal
group. The system can receive portal-initiated WPP request packets from any
configured portal in the portal group. When the system must initiate a WPP
NTF_LOGOUT message, it sends a NTF_LOGOUT message to all configured
portals in the portal group, and the first received ACK_LOGOUT stops
retransmission of the NTF_LOGOUT message.
This feature is also supported for WPP triggered hosts and SRRP/MCS.
• WPP over IPv6; for example, a BNG and portal can exchange WPP messages
over IPv6
• User client access portal over IPv6
• Dual-stack IPoE sessions. This means that the user client can be a dual-stack
device, such as:
- IPv4 only
- IPv6 only
- IPv4 and IPv6
For IPv6, the client can use a DHCPv6 IANA or SLAAC address to access the
portal.
Only the first address assignment of an IPoE session triggers WPP
authentication. Subsequent address assignments in the same session do not
require authentication. If IPoE reauthentication is enabled, when the system
requires reauthentication of the client, the system restores the SLA profile or
subscriber profile session to the initial WPP profile. This causes the client to be
redirected to the portal again to authenticate.
• WPP portal redundancy (portal-group) for IPv6 portal and dual-stack IPoE
session
• WPP LUDB support for dual-stack IPoE sessions
• WPP MCS redundancy for dual-stack IPoE sessions
• Triggered dual-stack IPoE sessions for Layer 3 access
- For these types of sessions, by default, each address of same client creates
a separate IPoE session unless the ipoe-session-policy circuit-id-from-
auth command is enabled and the RADIUS server returns a circuit ID
during WPP-triggered RADIUS authentication.
AN
PW-SAP2
epipe P
PW-PoRT1 PW-SAP2
P PW-SAP2
al_0066
Subscriber Interface
Group-Intf1
PW-SAP1
PW-PoRT1
PW-SAP2
SDP
Group-Intf2
PW-SAP1
PW-PoRT2
PW-SAP2
al_0067
For more information about PW ports, see the Pseudowire Ports section in the
7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL,
VPLS, PBB, and EVPN.
The router supports the MPLS entropy label (as specified in RFC 6790, The Use of
Entropy Labels in MPLS Forwarding) on fixed PW ports. This allows LSR nodes in a
network to load-balance labeled packets in a more granular fashion than allowed by
simply hashing on the standard label stack. For more information, see the 7450 ESS,
7750 SR, 7950 XRS, and VSR MPLS Guide, Entropy Label.
QoS is supported for ESM over PW SAPs as with ESM over regular SAPs, and
includes currently supported models.
• FC to queue mapping
• H-QoS
- Per-subscriber H-QoS (service scheduler child to port-scheduler parent).
- PW SAP queues attached to H-QoS scheduler by a parent statement.
Bandwidth control per PW port (per AN or per AN/ per service) by Vport.
config>
port 1/1/1
ethernet
mode hybrid
encap-type dot1Q
mtu 1540
access
egress
vport “v1” create
agg-rate
rate 1000
host-match dest “dslam-1” #### hosts will be associated with
exit #### vport based on inter-dest-id
exit
exit
exit
config>service>sdp>binding
pw-port 11 vc-id 11 create
egress
shaping int-dest-id “dslam-1” #### dynamic vport selection based on
#### int-dest-id.
config>
port 1/1/2
ethernet
mode hybrid
encap-type dot1Q
access
egress
With normal Ethernet aggregation in the next-mile, when last-mile shaping is on,
fixed encapsulation-offset is calculate based on the last-mile encapsulation type and
the next-mile encapsulation (26 bytes with qinq). This offset is applied to the frame,
and the ATM overhead is then dynamically calculated on the adjusted size. The
resulting dynamically calculated overhead in the data-path is then applied to the
queue-rates and the subscriber aggregate-rate.
14B Ethernet header + [4B] (optional network interface Q-tag) + MPLS Labels
(variable)
This feature provides support for stateful BNG redundancy. Such as when the far-
end aggregation PE (A-PE) is dual-homed to two BNGs terminating subscriber
sessions over MPLS pseudowires (PWs) that are initiated from the A-PE. The
subscriber state between the BNG pair is synced using MCS.
In this model, there is no SRRP message exchange between the BNG pair, as there
is no Layer 2 path between them. The purpose of SRRP is to get SRRP-aware
routing for subscriber routes and managed routes, or to be able to use the redundant
(shunt) interface. Downstream traffic for a subscriber that ingresses the standby
BNG can only be shunted to the active BNG, if the corresponding subscriber
interface on the standby BNG is operationally UP. This is achieved by creating a
second empty group interface (without SAPs) on the same subscriber interface with
the oper-up-while-empty command configured. Multiple PWs with endpoint
configuration is not supported on the BNG.
Active
PW
Redundant
Access SRRP MCS Interface
Nodes A-PE
Standby
PW
BNG
al_0070
config>
pw-port 2 create
exit
config>redundancy#
multi-chassis
peer 10.20.1.3 create
source-address 10.20.1.2
sync
srrp
sub-mgmt ipoe pppoe
port pw-2 sync-tag "tag2" create
exit
no shutdown
exit
no shutdown
exit
exit
exit
config>service>ies#
redundant-interface "redundant-interface" create
address 10.10.30.2/24 remote-ip 10.10.30.3
spoke-sdp 23:1000 create
no shutdown
exit
exit
config>service#
sdp 1 mpls create
far-end 10.20.1.2
ldp
keep-alive
shutdown
exit
binding
port 1/1/1
pw-port 2 vc-id 2 create
vc-type vlan #### default encaps-type dot1Q
no shutdown
exit
exit
no shutdown
exit
config>service#
subscriber-interface "subif" create
address 10.11.1.2/16 gw-ip-address 10.11.1.1 populate-host-routes
group-interface "grpif" create
authentication-policy "base_authpolicy"
redundant-interface "redundant-interface"
sap pw-2:1000 create
description "sap-grp-3"
exit
srrp 1 create
message-path pw-2:1000
no shutdown
exit
arp-host
host-limit overall 8000
min-auth-interval 1
no shutdown
exit
exit
exit
exit
config>
pw-port 2 create
exit
config>redundancy#
multi-chassis
peer 10.20.1.2 create
source-address 10.20.1.3
sync
srrp
sub-mgmt ipoe pppoe
port pw-2 sync-tag "tag2" create
exit
exit
no shutdown
exit
exit
exit
config>service>ies#
redundant-interface "redundant-interface" create
address 10.10.30.3/24 remote-ip 10.10.30.2
spoke-sdp 32:1000 create
no shutdown
exit
exit
config>service#
sdp 1 mpls create
far-end 10.20.1.2
ldp
keep-alive
shutdown
exit
binding
port 1/1/1
pw-port 2 vc-id 2 create
vc-type vlan #### default encaps-type dot1Q
no shutdown
exit
exit
no shutdown
exit
config>service#
subscriber-interface "subif" create
address 10.11.1.3/16 gw-ip-address 10.11.1.1 populate-host-routes
group-interface "grpif" create
authentication-policy "base_authpolicy"
redundant-interface "redundant-interface"
sap pw-2:1000 create
description "sap-grp-3"
exit
srrp 1 create
keep-alive-interval 1
message-path pw-2:1000
no shutdown
exit
arp-host
host-limit 8000
min-auth-interval 1
no shutdown
exit
exit
group-interface "dummy" create
oper-up-while-empty
exit
exit
exit
With VPLS based aggregation service from A-PE, normal SRRP message exchange
can take place between the active and standby BNGs. An active or standby decision
and switch-over is based on the SRRP state. An SRRP instance is configured per
group-interface corresponding to PW port. Fate-sharing groups (FSG) can be
configured for a set of SRRP instances (for example, SRRP instances corresponding
to PW ports sharing the same subnet). A standard oper-group grp-id should be
configured with messaging SAPs for all PW ports that are in the same FSG, and
monitor-oper-group grp-id should be configured under each SRRP instance in
same FSG. Existing SRRP support defined in Triple-play services guide for ESM
over regular group-interfaces and subscriber SAPs is applicable identically to ESM
over PW ports and PW SAPs.
With ESM over PW, redundancy in the aggregation network based on MC-LAG
between A-PE and dual BNGs is not supported.
VPLS PW
BNG
al_0069
config>
pw-port 1 create
exit
config>redundancy#
multi-chassis
peer 10.20.1.2 create
source-address 10.20.1.3
sync
srrp
sub-mgmt ipoe pppoe
port pw-1 sync-tag "tag1" create
exit
exit
no shutdown
exit
exit
exit
config>service>ies
redundant-interface "red-1-1" create
address 10.1.1.2/24 remote-ip 10.1.1.1
spoke-sdp 1:1 create
no shutdown
exit
exit
srrp 1 create
gw-mac 00:00:5e:00:01:01
keep-alive-interval 50
message-path pw-1:4000.1
monitor-oper-group "1" priority-step 10
no shutdown
exit
exit
config>service
customer 1 create
description "Default customer"
exit
sdp 1000 mpls create
far-end 10.20.1.2
lsp "lsp_1"
path-mtu 1600
keep-alive
no shutdown
exit
sdp 1002 mpls create
far-end 10.20.1.3
lsp "lsp_3"
path-mtu 1600
keep-alive
no shutdown
exit
vpls 1 customer 1 create
service-mtu 1600
stp
exit
exit
config>service
customer 1 create
description "Default customer"
exit
sdp 1002 mpls create
far-end 10.20.1.3
lsp "lsp_2"
path-mtu 1600
keep-alive
no shutdown
exit
The following example shows SRRP status, subscriber host, and routing information
on the active BNG (SRRP master state):
The following shows SRRP status, subscriber host, and routing info in standby BNG
(SRRP init state):
SRRP Instance 1
===============================================================================
Description : (Not Specified)
Admin State : Up Oper State : initialize
Preempt : yes One GARP per SAP : no
Monitor Oper Group : None
System IP : 10.20.1.3
Service ID : VPRN 3
Group If : grpif MAC Address : 1c:87:ff:00:00:00
Grp If Description : N/A
Grp If Admin State : Up Grp If Oper State: Down
Subscriber If : subif
Sub If Admin State : Up Sub If Oper State: Up
Address : 10.11.1.3/16 Gateway IP : 10.11.1.1
Redundant If : redundant-interfa*
Red If Admin State : Up Red If Oper State: Up
Address : 10.10.30.3/24
Red Spoke-sdp : 32:1000
Msg Path SAP : pw-2:1000
Admin Gateway MAC : Oper Gateway MAC : 00:00:5e:00:01:01
Config Priority : 1 In-use Priority : 1
Master Priority : 1
Keep-alive Interval : 1 deci-seconds Master Since : 05/29/2012 07:22:26
Master Down Interval: 0.000 sec (Expires in 0.000 sec)
Fib Population Mode : all
VRRP Policy 1 : None VRRP Policy 2 : None
===============================================================================
* indicates that the corresponding row element may have been truncated.
This section provides an example on how to configure PW port based capture SAP
that is used in ESM. For more information on PXC Based PW ports, refer to the
7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL,
VPLS, PBB, and EVPN.
PXC Configuration
configure
port-xc
pxc 1 create
port 1/1/1
no shutdown
pxc 2 create
port 2/1/1
no shutdown
With this configuration, ports 1/1/1 and 2/1/1 are auto-provisioned in hybrid mode
operating as individual loopback ports. The SR OS system automatically creates a
pair of sub-ports per PXC. Those sub-ports are by default in shutdown state:
configure
port pxc-1.a
shutdown
port pxc-1.b
shutdown
port pxc-2.a
shutdown
port pxc-2.a
shutdown
configure
lag 1 create
port pxc-1.a
port pxc-2.a
lag 2 create
port pxc-1.b
port pxc-2.b
FPE Configuration
configure
fwd-path-ext
fpe 1 create
path xc-a lag-1 xc-b lag-2
pw-port
PW port creation — The PW port must be explicitly created in the SR OS, before
mapping between PW and PW port can be performed.
SDP Creation for the External PW — The following displays an SDP configuration for
the external PW.
configure
service
sdp 1 create
signaling tldp
far-end 10.1.1.1
Mapping Between the External PW and the PW port — The stitching of the external
PW and PW port is configured through an Epipe in vc-switching mode.
configure
service
epipe 10 customer 1 vc-switching create
spoke-sdp 1:100 create
pw-port 100 fpe 1
configure
service vpls 2 create
sap pw-port-100:3.* capture-sap create
From here, ESM functionality is applied to the PW-SAP in the same manner as on
any other regular SAP.
configure
service
epipe 10 customer 1 vc-switching create
sap 1/1/1:10.* create
pw-port 100 fpe 1
In this example, the outer VLAN tag 10 in the payload is removed on ingress and the
payload is delivered to the PW port where it can be mapped to a capture PW-SAP.
This scenario allows traffic distribution from a single I/O port to different EMS
termination points (anchor line cards) based on outer VLANs.
Redundant BNGs with EVPN VPWS in the access area of the network rely on the
EVPN Single-Active (SA) multihoming concept with PW ports in Ethernet Segments
(ES). A PW port on one side in the ES is elected as the Designated Forwarder (DF)
and the other side as the non-Designated Forwarder (NDF). The ES with the PW port
as DF is operationally up, and conversely, the ES with the PW port as NDF is
operationally down. The DF side is the active side while the NDF side is the standby
side. SRRP, as part of subscriber management redundancy scheme, indirectly
tracks ES states to determine which BNG side is active and which is standby. With
multiple EVPN VPWS instances, the load is distributed between the redundant BNGs
where one BNG can be active for one set of EVPN VPWS while the other BNG can
be active for another set of EVPN VPWS instances. The operator can influence the
selection of the active side (DF side) for each EVPN VPWS by configuring a higher
preference number on the preferred DF side.
The SRRP state must transition into a standby state on the NDF side even if the PW-
port is operationally up. To achieve this, the SRRP messaging PW SAP goes through
an oper-group that tracks the state of the ES, whose operational state is up on the
DF side and down on the NDF side
The basic concept of this approach, where the messaging SRRP PW-SAP is tracking
the state of the ES, is shown in Figure 133. There are two key concepts introduced:
FD BNG1
P/B
A SRR Messaging SAP
BG pw-1:10 ESM
epipe 1 DF Sub-if IP
pw-1:11 sub-if routes
EVPN pw-1:12 grp-if
IGP/BGP
IP@1 PW-port 1 pw-1:n (low cost)
WS
AN N VP
EVP
MCS Redundant-
epipe 1 (subscriber interface
SAP 1/1/1:* EVPN BGP/BFD ES 1 states are (optional)
synched)
EVP
N VP BNG2
WS B SRR Messaging SAP
epipe 1 NDF pw-1:10 ESM Sub-if IP
BG pw-1:100 sub-if
P/B EVPN pw-1:200 grp-if routes
FD IGP/BGP
PW-port 1 (high cost)
pw-1:n
configure service
epipe 1
bgp-evpn
evi 1
mpls
auto-bind-tunnel
resolution any
pw-port 1 fpe 10
oper-up-on-mhstandby
configure service
vprn 1
subscriber-interface ‘demo-sub-if-1’
group-interface ‘demo-grp-if-1’
sap pw-1:1.10
monitor-oper-group demo-ES1
srrp 1
messaging-path pw-1:1.10
sw1262
The following is a detailed description of the setup with a single EVPN VPWS and
two BNGs (Figure 133).
• One BNG in the EVPN is selected as the DF (BNG1), the other BNG (BNG2) is
the NDF.
• BNG2 bring its ES down.
• Only BNG1 advertises its AD route towards the access node.
Consequently, the AN does not send any traffic to BNG2 (NDF). Instead, the AN
sends all traffic only to BNG1 (DF).
• The ES is part of an oper-group (OG) which is monitored from the ESM side.
• The stitching Epipe on BNG2 does not change its status. Neither does the PW
port in it. The PW port stays up despite the MHStandby flag being raised.
Normally, the MHStandby flag would cause the PW port to go down, but due to
the oper-up-on-mhstandby configuration option, this behavior is overridden.
• ESM subscribers are synchronized between the chassis through MCS and are
using SRRP on the access side. With EVPN in the access, SRRP is not relying
on its own keepalives to check the health of the network path, but instead, it
follows the state of the PW port or the ES. If the PW port is operationally up, the
messaging PW SAP is up, and therefore the SRRP is active. Conversely, if the
PW port is operationally down, the messaging PW SAP is down and
consequently SRRP is in the backup state. This is the expected behavior when
the EVPN MPLS destination (network bind) goes down.
However, in the SA multihoming scenario, when the EVPN MPLS destination is not
down, the PW port remains up even if the PW port is an NDF. Instead of relying on
the PW port state, the SRRP messaging PW SAP monitors the state of the ES
through an oper-group. When the oper-group changes its state to down, so does the
SRRP messaging PW SAP, which then forces the SRRP into an INIT state (which is
equivalent to a standby state).
• On the network side, the state of the SRRP controls the advertisement of the
subscriber IP routes into the network. Subscribers routes are advertised with a
lower cost from the active SRRP node than they are from the standby SRRP
node.
• The solution described above protects against failures in the access part of the
network or BNG node failure. Optionally, network side ports can be placed in an
oper-group that can be monitored from the EVPN side. This can be used to
protect against network port failures.
LLID serves the purpose of abstracting the physical line of the user from the ISP. If
the user moves to a new physical line, the RADIUS server database maintaining the
physical line of the subscriber to LLID is updated. Because a subscriber’s LLID
remains same regardless of subscriber’s physical location, using LLID gives service
provider a stable and secure identifier for tracking subscriber.
The local user database assigned to the PPPoE node under the group interface can
have both a pre-authentication policy and an authentication policy. The purpose of
the pre-authentication policy is to retrieve the LLID from the AAA server. The pre-
authentication only extracts the calling-station-id attribute (0x31) which is used as the
LLID, anything else returned during pre-authentication are simply ignored. If the pre-
authentication is missing the LLID, the session moves on to the authentication policy.
In the authentication policy that follows, it is possible to use the LLID as the calling-
station ID.
It is possible to convey LLID from the LAC to the LNS. The LLID is retrieved through
PPPoE pre-authentication where the returned RADIUS attribute calling station ID is
used as the LLID. This LLID is selectable attribute in L2TP as a calling-number (AVP
22) to be passed from LAC to LNS. At the LNS, the subscriber calling station number
is retrieved from AVP 22 and can be included as an attribute during authentication.
The LUDB must be configured on the capture SAP. Without the LUDB
specified, the existing functionality is performed for MSAP creation.
3. The LUDB host entry is matched to the entry that has the PADI
authentication policy.
4. RADIUS authentication and MSAP authorization occurs.
5. An MSAP is created if the authentication policy is not configured for PAP/
CHAP.
2. (Optional) LLID pre-authentication:
1. Look up the LLID pre-authentication policy under the LUDB host entry.
2. Perform RADIUS pre-authentication to obtain an LLID.
3. LCP authentication and L2TP tunnel authorization:
1. Trigger RADIUS authentication defined by the authentication policy
configured in the LUDB host entry in the previous step.
2. Create the MSAP, finish the LCP authentication with the PPP client, and
establish an L2TP tunnel/session.
PPPoE
BNG
Client
sw0062
9.17.1 Terminology
• LUDB – Local User Database configured within the 7450 ESS and 7750 SR.
• IP Address Assignment with DHCP Relay — IP address assignment request
(DHCP or IPCP) from the host is relayed to an internal or external DHCP server.
A gi-address must be present in this relayed request while the pool name is
optional. The internal DHCP server may select the IP address from is local pool
based on the gi-address or based on the pool-name present in the request. The
IP address selection method is configuration dependent. Third party DHCP
servers may consider additional fields in IP address selection process (mac
address, circuit-id, and so on).
• IP Address Assignment with DHCP Proxy — A preconfigured IP address in
LUDB or RADIUS server is handed out to the host using a DHCP proxy function.
This proxy function responds natively using DHCP protocol to the IPoE host.
Although PPPoE hosts are not utilizing DHCP protocol, the DHCP proxy
functionality within the server is still needed for successful IP address delegation
to PPPoE hosts.
- DHCP parameters that came from standard DHCP options returned by the
DHCP server directly
- Information extracted from options (strings-from-options). This is applicable
for IPoE and PPPoE (DHCP client) that use a local DHCP server with
LUDB.
- DHCP ACK Python
9. defaults, if any
For example, if the same ESM parameter is provided through both authentication
sources, LUDB and RADIUS, the ESM parameter from LUDB always overrides the
ESM parameter obtained from RADIUS.
The settings that allow swapping of the LUDB and RADIUS priorities as
authentication sources are configured on the system level as follows.
Classic CLI:
subscriber-mgmt
authentication-origin
[no] priority <id> source <string>
exit
exit
The only accepted configuration option is id 3 and RADIUS as the source string. This
configuration moves RADIUS to position 3 and shifts everything from the previous
position 3 downward.
The defaults are restored by using the no form of the priority command.
The active order of priorities can be displayed in the output of the show>subscr-
mgmt>authentication-origin command:
8 dhcp
-------------------------------------------------------------------------------
Number of Authentication Origins : 8
===============================================================================
*A:cses-V26>config>subscr-mgmt>auth-orig# priority 3 source radius
*A:cses-V26>config>subscr-mgmt>auth-orig# show subscriber-mgmt authentication-origin
===============================================================================
Authentication Origins
===============================================================================
Priority Source
-------------------------------------------------------------------------------
1 python
2 diameterGx
3 radius
4 ludb
5 diameterNasreq
6 localAddressAssignment
7 gtp
8 dhcp
-------------------------------------------------------------------------------
Number of Authentication Origins : 8
===============================================================================
*A:cses-V26>config>subscr-mgmt>auth-orig#
The following describes the configuration logic where both LUDB and RADIUS are
accessed during authentication phase:
• LUDB is referenced under the capture SAP (if the capture SAP is deployed) and
the group interface (DHCP, DHCP6, or PPPoE).
• The authentication policy is referenced in LUDB (and not under the capture SAP
and group interface).
With this approach, LUDB is accessed first and subscribers can be authenticated
based on generic criteria, such as a range of VLANs or a default user. The ESM
parameters obtained in this step are stored.
9.17.3 No Authentication
IPoE and PPPoE v4/v6 hosts on static SAPs can be instantiated without the need to
access LUDB or RADIUS server. In this case, the default subscriber host parameters
(sla-profile, sub-profile, subscriber-id) must be provisioned statically under the SAP.
The IP address assignment is provided by internal or external DHCP server. The IP
address selection on the router based DHCP server is based on the gi-address while
third party DHCP servers may provide additional means to select the IP address
(mac-address, circuit-id, and so on).
A DHCP pool name cannot be provided by an SR-series router DHCP relay agent,
since the LUDB and/or RADIUS are not utilized.
This model does not support IP address delegation by DHCP Proxy function since
there is no LUDB or RADIUS server available that can supply pre-configured IP
address.
Pool names for DHCP relay function (IPv4, IPv6 IA-NA, IPv6 IA-PD)
Fixed IP addresses – IPv4, IPv6 IA-NA, IPv6 IA-PD and IPv6 SLAAC prefix.
In case of capture SAP, the LUDB name configured under the capture SAP must
match the LUDB name under the group-interface>dhcp/ppp hierarchy. If the LUDB
names do not match, the subscriber-host instantiation fails.
ESM strings can also be provided by LUDB queried by the DHCPv4 server.
Accessing LUDB directly by DHCPv4 server should be used in rare and exceptional
cases.
In case of capture SAP, the authentication policy must be applied under the capture
SAP. This authentication policy name must match the authentication policy name
that is configured under the group-interface. Otherwise, the host instantiation fails.
If LUDB and authentication policy are configured simultaneously under the group-
interface (and possibly under the capture SAP), the RADIUS authentication policy
evaluates and LUDB is ignored.
The fallback action takes effect once the preconfigured RADIUS timeout period
expires.
RADIUS fallback is not supported for DHCPv6 hosts for non-IPoE sessions but is
supported for IPoE sessions.
9.18.1 Terminology
Subscriber host — A representation of an external host requesting a service. Each
such host is fully instantiated within the 7450 ESS and 7750 SR for the purpose of
providing traffic control and billing services (for example, QoS, filtering, antispoofing,
accounting). The external hosts may represent variety of devices such as regular
PCs, STBs, residential gateways, CPEs, VoIP devices. In most cases, the external
host runs a DHCPv4/v6 or PPPoEv4/v6 client. DHCP and PPPoE initiation
messages from such clients triggers host instantiation within the router. For this the
subscriber host term can be interchangeably used with a term DHCP client or PPPoE
client.
IPv4: Framed-IP
(and framed-mask and default-gw)
OR
7x50-BNG IPv6: Framed prefix or delegated prefix Retailer Y
AN
RGs Retail
VRP X
Retail
VRP Y
AAA-Z
al_0176
In scenarios where the retail service provider wants to maintain independence from
the IPv4 addressing scheme deployed in the BNG (that is controlled by wholesaler),
the retailer can always supply its own IPv4 address, the subnet mask and the default-
gw IPv4 address. But if the default-gw IPv4 address and/or subnet mask is not
supplied by the retailer, then they are auto-generated by the BNG. Once the default-
gw IPv4 address is auto-generated, it is sent to the requesting DHCP client by DHCP
offer in option 3 (RFC 2132, Router Option, section 3.5). There is no additional
configuration needed for this action. The BNG automatically detects whether the
default-gw IPv4 address is supplied by LUDB, RADIUS or DHCP server and acts
correspondingly.
The default-gw IPv4 address is auto-generated based on the assigned IPv4 address/
mask by setting the last bit of the assigned host IPv4 address to binary 01 or binary
10. For example if the subscriber host’s assigned IPv4 address is 10.10.10.10
255.255.255.0, then the default-gw IPv4 address is set to 10.10.10.1. If the assigned
IPv4 address is 10.10.10.1 255.255.255.0, then the auto-generated default gateway
IPv4 is set to 10.10.10.2.
The default gateway IPv4 address always must be within the subscriber’s subnet. If
it is not, the behavior might be inconsistent. For example:
The subscriber is successfully instantiated in the BNG, but the client may not ARP
for a default-gw outside of its configured subnet. Whether the client does or does not
ARP for a default-gw outside of its configured subnet depends on the implementation
in the RG and CPE.
For example:
RADIUS or DHCP server assigns IPv4 address and subnet mask to the first host in
a bridged environment:
IP1: 10.10.10.1
Since the RADIUS and DHCP Server are not aware of the auto-generated default-
gw, they may assign the following IPv4 address to the second host that comes on-
line:
IP 2: 10.10.10.2 (same IPv4 address as the default-gw IPv4 address of the first host)
Now the first host forwards all traffic outside of the configured subnet to the second
hosts which discards this traffic, effectively rendering this operation model non-
deployable. And vice versa.
For example, if the operator owns the IPv4 subnet 10.10.10.0/24, then one IPv4
address can be set aside for the default-gw (for example 10.10.10.254) and the
remaining addresses can be assigned to the subscriber (routed RGs or CPEs). An
example would be:
Once RG-1 ARPs for its default gateway of 10.10.10.1, the BNG replies with its own
MAC address.
Now that host RG-1 has resolved ARP for it default-gw (MAC address pointing to the
router), it can send traffic to the outside world by the BNG. When such traffic arrives
to the router, the destination IPv4 address of the received packet determines the
forwarding decision within the router. If the destination IPv4 address matches the
IPv4 address of any subscriber (RG) instantiated within the system, the traffic is
forwarded to the that RG. This also includes the case where the destination IPv4
address is the default-gw IPv4 address (10.10.10.1), which represents just another
RG within the router. The traffic is consequently passed from RG-1 by 7450 ESS and
7750 SR to RG-2.
For example, if the RADIUS received IPv4 address is 10.10.10.138 and the received
default –gw IPv4 address is 10.10.10.170, then the subnet mask is auto-generated
and set to 255.255.255.192 (/26).
138 = 10001010
170 = 10101010
192 = 11000000
In case that neither the subnet mask nor the default-gw are returned, then both would
be auto-generated:
In cases where the host IPv4 address and the default-gw are directly supplied by the
addressing authority but the subnet mask is missing, the subnet mask auto-
generation may cause the host part of the default-gw IPv4 address to become a
broadcast IPv4 address. If this is an issue, then it can be avoided by directly
providing the subnet mask by the addressing authority.
The local-proxy-arp command ensures that the router answers ARP Requests with
its own MAC address for any active IPv4 address under the subnet on which the ARP
request arrived. The active IPv4 address is considered the one that is assigned to an
already instantiated hosts or the default-gw (even auto-generated).
In absence of local-proxy-arp command, the only ARP Request that the router’s
answer is the one for the statically configured IPv4 addresses of the subscriber-
interface. In flexible IPv4 addressing, the IPv4 address of the default-gw does not
necessarily match any of the configured subscriber-interface IPv4 addresses. The
ARP Request for such default-gw IPv4 address would go unanswered.
Consequently, the subscriber hosts would not be able to communicate with outside
world. Therefore, the flexible IPv4 addressing requires that the local-proxy-arp
command is configured.
When the arp-populate command is disabled the ARP entries are dynamically
learned based on the ARP protocol. This, in conjunction with flexible IPv4 addressing
may cause certain issues. Consider the following example:
In this case, downstream traffic towards the subscriber host triggers the router to
send ARP Request for the subscriber host IPv4 address. The router needs to know
the MAC address of the subscriber-host to forward traffic. Since the subscriber-
interface is unnumbered, the source IPv4 address of the ARP request is unknown
and consequently, the ARP request are not sent. As a result, downstream traffic is
dropped.
However, the above example is an unlikely scenario. If the subscriber host sends the
ARP request for the default-gw first, the router would create an entry in the ARP table
for it and the issue would be resolved. This is the most likely outcome since the
subscriber host always tries to initiate communication with the outside and therefor
ARP for the IPv4 address of the default-gw (which is a 7450 ESS and 7750 SR).
configure subscriber-mgmt
shcv-policy "shcv-policy-1" create
layer-3
unnumbered-source-ip 192.0.2.1
exit
exit
SLAAC hosts are installed as /64 entries, the length of the installed DHCP-PD prefix
is dictated by the prefix-length and the DHCP-NA hosts are installed as /128 entries.
IPv4:
By default, IPoE and PPPoE subscriber host creation fails in the following two cases:
Subscriber host instantiation and forwarding can be explicitly enabled for both cases
above with flexible IP addressing functionality.
For case 1, this can be achieved by borrowing an IP address for the subscriber-
interface from any interface that is operationally up within the given routing context.
This functionality can be enabled with the configure service ies | vprn <service-
id>>subscriber-interface <ip-int-name> unnumbered <ip-int-name | ip-address>
command.
To enable forwarding for the subscribers whose IP address falls outside of the
configured subnet under the subscriber-interface (case 2), the configure service
ies | vprn <service-id> subscriber-interface <ip-int-name> allow-unmatching-
subnets command must be entered.
In both of these cases the host is installed in the routing table as /32.
IPv6:
For IPv6 there is a single command that enables flexible IP addressing for both
cases:
• PPPoEv4
- An IPv4 address under the subscriber-interface is configured
• By default, hosts outside of the sub-intf subnet are instantiated but they
are in a non-forwarding-state. Traffic is dropped.
• allow-unmatching-subnets is configured. This command is allowed
only if subscriber-interface has also configured its own IPv4
address(es). In this case the IP address for IPCP negotiation is one of
the sub-intf addresses. Hosts outside of the sub-intf subnets are
instantiated and forwarded.
• The unnumbered <ip-address | ip-int-name> command is not allowed
in this scenario.
- An IPv4 address under the subscriber-interface is not configured
• By default, the subscriber-interface is operationally down. Subscribers
cannot be instantiated.
• The allow-unmatching-subnets command has no effect since
subscriber-interface does not have an IPv4 address configured and is
therefore operationally down. No subscribers can be instantiated.
• The unnumbered <ip-address | ip-int-name> command is the only
viable option in this case. The subscriber-interface borrows an IPv4
address from another interface that is operationally UP and
consequently this allows subscribers to be instantiated. This command
is mutually exclusive with allow-unmatching-subnets. In addition, this
command can only be configured if the subscriber interface itself does
not have explicitly configured an IPv4 address.
• IPoEv4
9.18.12 Caveats
• Auto-generation of the default-gw IPv4 address is supported only in RCO model
with routed RGs/CPEs. Bridged RGs/CPEs are not supported.
• A configured IPv4 address cannot be removed from the subscriber-interface
when DHCPv4 hosts under the corresponding subnet are instantiated in the
system.
For IPv4, uRPF is supported on group interfaces using anti-spoofing filters. A group
interface configured for NATed subscribers is configured with MAC/IP/PPPoE
Session-ID anti-spoofing filters.
IPv6 subscribers, which are non-NAT, are always treated as being on a local subnet.
For such subscribers, a BNG installs an FDB entry for local routes that match either
the wan-host prefix, or the delegated prefix, or both. In strict mode for IPv6 ESM, the
uRPF check checks not just that the route matching the SA (which should be a local
route, such as a subnet) would route the packet back out of the interface it came in
on, but in addition that we would route the packet out to the same SAP it was
received on.
config>service>vprn>if>sap
config>service>ies>sub-if>grp-if>sap
config>service>vprn>sub-if>grp-if>sap
config>subscr-mgmt>msap-policy
A uRPF check is also performed that prefixes delegated to a subscriber on that MAC
address exist in the FDB.
An IPoE session is a logical grouping of IPoEv4 and IPoEv6 subscriber hosts that
represent the different IP stacks of a single end device and that share authentication
data such as subscriber id, subscriber and SLA profile, session-timeout, and so on.
The grouping of subscriber hosts in an IPoE session is based on a configurable
session key per group-interface. The IPoE session key includes by default the SAP
identifier and MAC address and can be extended with Circuit-Id/Interface-Id or
Remote-Id. For DHCPv6 Remote-Id, the enterprise number is excluded from the
session-key. Circuit-id/Interface-Id or Remote-id should only be used in the IPoE
session key if all subscriber host associated with the IPoE session have this field in
their protocol trigger packets. The IPoE session creation (Figure 136) or subscriber
host association to an IPoE session fails if the Circuit-Id/Interface-Id or Remote-id is
not present in a trigger packet while the field is part of the session-key.
IPv4 DHCPv4
Subscriber IPoE
wan: DHCPv6 IA-NA
Session
IPv6 wan: SLAAC
pd: DHCPv6 IA-PD
al_0631
An IPoE session represents a single end device and can have following associated
IP stacks:
A violation of the above rules results in a setup failure of the subscriber host when
an attempt is made to associate it to the IPoE session.
Important Notes:
If there are active IPoE sessions on the group-interface, be aware that disabling IPoE
sessions on the group-interface results in service impact for those sessions.
DHCPv4 Request
DHCPv6 Request
Router Solicitation
DHCPv6 Request
A new local user database config in the ipoe-session CLI context on a capture SAP
or group interface ensures that all subscriber hosts associated with an IPoE session
are using the same database and therefore common match criteria. The per
subscriber host type user-db configurations, such as ipv6 dhcp6 user-db, dhcp
user-db and rtr-solicit-user-db are ignored when IPoE sessions are enabled.
With session accounting, a RADIUS accounting start is generated when the first host
of the session is created and an accounting stop when the last host of the session is
deleted. The generation and interval of periodic interim updates can be configured.
Optionally, triggered interim update messages can be generated when a host is
deleted from the session or an additional host is associated.
A unique accounting session id is generated for the IPoE session and is used in
RADIUS session accounting. The IPoE session accounting session id can be
included in the RADIUS Access Request message the config>subscr-mgmt>auth-
plcy# include-radius-attribute acct-session-id session command.
A RADIUS CoA message targeting any host of an IPoE session has the same effect
as a Radius CoA message targeting the IPoE session using the IPoE session Acct-
Session-Id as key: all host of the session are targeted and the session state is
updated with the new data.
An IPoE session and all associated subscriber hosts can be deleted by the following:
It should only be used in a subscriber per VLAN model as the session index is per
SAP.
The SAP session index allows IPoE sessions in a bridged RG environment to have
their own set of queues for QoS and accounting purposes when using the same SLA
profile name received from a RADIUS server. See Subscriber per PPPoE Session
Index for further details.
Alternatively, this can be achieved by configuring per-session SPI sharing in the SLA
profile as described in SLA Profile Instance Sharing.
9.20.8 Resiliency
For non-redundant BNG deployments, the IPoE session state is stored in the
subscriber-mgmt persistency file for recovery from Compact Flash after a node
maintenance operation or failure. This is configured at the system persistence CLI
context.
For multi chassis redundancy scenarios, the IPoE session state is synchronized by
the “sub-mgmt ipoe” Multi Chassis Synchronization (MCS) application.
9.20.9 Notes
• Static hosts can be configured on a group-interface with IPoE sessions enabled.
A static host is not associated with an IPoE session.
• Up to sixteen Framed-Routes and sixteen Framed-IPv6-Routes can be
associated with an IPoE session.
• A fall back action (accept or local user database lookup) when no Radius servers
are available for Radius authentication can be specified for IPoE sessions.
• Lawful Intercept sources initiated from Radius always include all IP stacks from
the IPoE session regardless the targeted host in the CoA message.
• ARP hosts are not supported in an IPoE session and cannot be instantiated on
a group-interface with IPoE sessions enabled.
• The creation of an IPv4 host using the Alc-Create-Host attribute in a Radius CoA
message is not supported on a group-interface with IPoE session enabled.
• A local user database host identification based on option60 is ignored when
authenticating an IPoE session.
• RADIUS authentication of an IPoE session fails when the user-name-format is
configured to mac-giaddr or ppp-user-name.
• The DHCP Python module (alc.dhcp) used to derive subscriber host attributes
from a DHCPv4 ACK message is not supported in combination with IPoE
sessions.
• A RADIUS CoA message containing an Alc-Force-Nak or Alc-Force-Renew
attribute is not supported for IPoE sessions
config
subscr-mgmt
ipoe-session-policy "ipoe-policy-1" create
description "Default IPoE session policy"
session-key sap mac # default
no session-timeout # default
exit
config
service
user-db "ludb-1"
no shutdown
exit
The duration of a migration is therefore dependent on the lease times for DHCPv4
and DHCPv6 hosts and for IPoE linked SLAAC hosts. If possible, the lease times
could temporarily be reduced to a couple of hours to facilitate the migration process.
The actual migration is started by the arrival of a new trigger packet of an IP stack
(host) that is not associated with an IPoE session. The IPoE session key is
composed of the data in the trigger packet (MAC address and SAP, by default). If an
IPoE session exists for the obtained IPoE session key, the corresponding session
data is used for authentication. If no IPoE session exists for the obtained IPoE
session key, authentication is performed, and based on the result, a new IPoE
session is created. The old host state is deleted from the system and a trap is sent
to indicate that this host is being migrated. A new host (IP stack) is created and
associated with the IPoE session. When RADIUS accounting is enabled, this may
result in an accounting start and stop depending on the accounting mode. For host
accounting, an accounting stop is followed immediately by an accounting start. For
queue instance accounting, an accounting stop is generated when the last host
associated with the queue instance is migrated. An accounting start is generated
when the first host is associated with the IPoE session.
• For multi-chassis redundant nodes, IPoE sessions should be enabled first on the
standby node and immediately thereafter on the active node.
• A renew as part of a DHCPv4 lease split operation does not trigger a migration
to the IPoE session. The migration starts only when the renew is forwarded to
the DHCP server.
• For DHCPv4 RADIUS proxy scenarios, it is recommended that the lease time be
specified the with the [26-6527-174] Alc-Lease-Time RADIUS attribute instead
of the [27] Session-Timeout attribute. After migration, the [27] Session-Timeout
attribute is interpreted as the number of seconds before the session is
terminated.
• DHCPv6 IA-PD modeled as a managed route may migrate separately from the
IPv6 SLAAC host it is associated with for its next-hop. This could result in a
temporary service impact until both the managed route and next-hop host are
migrated.
• The migration of idle Router Solicit SLAAC hosts can be facilitated by specifying
an inactivity timer.
• When the subscriber ID is auto-generated (auto-sub-id), then a new sub-id is
be generated after migration. This may result in a temporary increase in used
resources such as queues until all hosts from a subscriber are migrated.
Important Notes
• It is recommended that a migration plan be built for the target network and
validate the plan in advance in a lab environment.
• It is recommended that the migration be performed per group interface or
capture SAP with all possible target group interfaces and that the next migration
only be started when the previous one is successfully completed.
• When managed SAPs (MSAPs) are used, enabling an IPoE session on a group
interface while not enabling IPoE sessions on the corresponding capture SAP,
or enabling an IPoE session on a capture SAP while not enabling IPoE sessions
on the target group interface, results in session setup failures for sessions where
no MSAPs exist.
1. Using the CLI commands described at the beginning of this section, check if an
IPoE session migration is applicable. A migration is not required when there are
no active subscriber hosts on the target group interfaces.
2. Check if all preconditions are met:
a. There are no conflicting requirements with IPoE sessions such as ARP host
support on the same group interface or local user database authentication
based on option 60. Check the Notes section above for a list of possible
conflicts.
b. IPoE session configuration is complete on the group interfaces and
corresponding capture-sap: ipoe-session-policy (session-key) and on
the optional local user database. On the group interfaces, the IPoE session
limits should be configured as needed using the session-limit and sap-
session-limit commands.
=========================================================================
6. Perform post migration steps. For example, verify that the number of users prior
to and after the migration are in the same order of magnitude (users may
connect and disconnect during the migration). Enable session accounting if
required.
During the migration of an IPv4 host as a control channel for Dynamic Data Services
to an IPoE session as a control channel, the associated dynamic data services are
deleted and recreated based on the IPoE session authentication data.
When IPoE sessions are enabled on the group interface, at the next DHCPv4 renew
or rebind:
Data-triggered host creation does not rely on protocol triggers (DHCP, PPPoE) or
management triggers (static hosts) to create each host, and is especially useful in
the following cases:
Step 1. The subscriber SAP, including MSAP, receives a user packet that does not
match existing anti-spoof table entries.
Step 2. BNG instantiates an IPoE session if there is no existing session with the
same session key, and performs authentication using LUDB and RADIUS.
Step 3. A subscriber host is created with the ESM strings provided during
authentication.
Step 4. The subscriber host is deleted when session-timeout or idle-timeout
expires, CoA triggers a disconnect, SHCV check failure, or management
(CLI, SNMP, and so on) triggers a host deletion.
An IPoE session and ARP population are mandatory when configuring data-
triggered ESM.
To terminate IPv6 hosts that send neighbor RS/NS before sending data packets,
auto-reply must be configured:
For MSAP, the “data” trigger packet type can accept data triggers:
To identify the source IPv4/IPv6 address of data-trigger packets, the IP prefix in the
local user database can be configured with host-identification:
Note: Only one IP prefix can be configured for each host. A dual-stack host requires two
local user database host entries if the IP prefix needs to be used for host identification.
For RADIUS authentication, the circuit ID includes the source IPv4/IPv6 address of
the data-trigger packet:
If IPoE session policy uses circuit ID to identify each session, a new IPoE session is
created for each source IPv4/IPv6 address. However, RADIUS can return the circuit
ID to merge multiple IPoE sessions with the same SAP, MAC, and circuit ID into a
single session.
A host is created using the IPv4/IPv6 source address of the data trigger (a /32
address for IPv4 or a /128 address for IPv6), but IPv6 data-triggered hosts can be
created as an IPv6 prefix by configuring ipv6-delegated-address in the local user
database host entry.
RADIUS can return the following AVPs to model the address/prefix of the data-
triggered host:
After a data-triggered host is created, DHCP packets sent by the client starts the
DHCP promotion process as follows:
Note: DHCP relay promotion is only supported when using RADIUS. LUDB and NASreq is
not supported.
Data
Access Request (IP, MAC)
Access Accept
(ESM attributes,
Alc-Force DHCP-Relay)
Create
Host
Data
Create
Lease
State
No3488
• Data-triggered IPv6 ESM hosts are created with the prefix specified by LUDB,
RADIUS, or from a source address of the data-trigger. The host creation fails if
an overlapping address and prefix is found in the host table.
• Data-triggered IPv6 ESM host creation fails if AAA returns a Framed-IPv6-Pool
AVP with no addressing information.
• Protocol-based IPv6 ESM host creation with LAA fails if LAA returns the address
and prefix overlaps with an existing data-triggered ESM host.
• IPoE sessions and their hosts (DHCP,DHCP6,SLAAC, and DT) are not
synchronized by the subscriber management IPoE MCS client.
• SRRP is synchronized over MCS.
• Active BNG in the (SRRP master state) only processes the data-trigger and
authenticates and creates a subscriber host state.
• Standby BNG in the (SRRP non-master state) discards all upstream packets.
• Shunt and redundant interfaces are not supported.
• After an SRRP switchover, the new active BNG starts processing subscriber
traffic. The previous active BNG deletes all IPoE sessions and IPoE subscriber
hosts on an SRRP switchover. Accounting stops are sent to indicate that this
node became standby (non-master SRRP state). Accounting messages are
different based on the radius-accounting-policy configuration.
1. queue-instance-accounting: accounting-stop with Alc-Error-Code = Node
has switched to stateless backup
2. session-accounting: interim-update with Alc-Acct-Triggered-Reason =
Node has switched to stateless backup, upon each stack deletion if host-
update is configured, and accounting-stop with Alc-Error-Code = Node has
switched to stateless backup
3. accounting: accounting-stop with Alc-Error-Code = Node has switched to
stateless backup, upon each host deletion
• The DHCP local server state can be synchronized for DHCP promotion.
• DHCP promotion for BRG requires lease state synchronization between
redundant BNGs, which disables protocol-triggered IPoE ESM without an IPoE
session. This requires the config>service>ies | vprn>sub-if>grp-if>ipoe-
session>stateless-redundancy command to be configured.
- host-PPPoE (PTA and LAC) processing can be tied with an SRRP instance
for stateless redundancy. Only the active BNG (SRRP master state)
processes PPPoE/PPP control plane data. A standby BNG (SRRP non-
master state) does not send LCP echo messages. After switchover,
subscriber hosts retry to connect after echo timeout.
• Supports both static SAP and MSAP.
Create
Host
Data
Link/Node
Failure
gARP
Data
Access Request (IP, MAC)
Access Accept
(ESM attributes)
Create
Host
Data
No3489
Stateless redundancy does not have information on MSAP because MCS is not used
for synchronizing subscriber host information.
Static SAPs must be configured to rewrite FDBs on Layer 2 switches with G-ARP in
access or aggregation networks.
group-interface <ip-int-name>
sap <sap-id> create
no shutdown
This requires the aggregation network to re-learn MAC for multiple C-VLANs using a
single G-ARP from a specific C-VLAN.
• MSAP has qinq encap, and aggregation switches have per SVLAN FDB
• MSAP has dot1q encap, and aggregation switches have per SVLAN FDB
(Aggregation switches push SVID)
IPv6 prefix learning is enabled with the following LUDB configuration conditions.
DHCP promotion is also supported on the data-triggered host created with IPv6
prefix learning.
The subscriber service functionality is built using the flexible RADIUS Python script
interface to populate the subscriber service data structure using a parameter list
received in subscriber service-specific RADIUS Vendor Specific Attributes (VSAs).
The format and content of the VSA parameter list is defined by the operator. An
accounting start/stop is sent when the subscriber service is activated/deactivated.
Optionally, interim updates can be sent in intervals that can be specified per
subscriber service instance. Accounting interim updates and stop messages contain
the subscriber service-related statistics (time or volume and time).
• QoS overrides: changing queue or policer parameters (PIR/CIR rates and CBS/
MBS burst sizes), adapting rates of a parent scheduler, root arbiter, or
subscriber aggregate rate
• PCC rules: applying QoS or filter actions to a set of IP flows
VSA Name
26-6527-151 Alc-Sub-Serv-Activate
Access-Accept Accounting Request
26-6527-152 Alc-Sub-Serv-Deactivate
or CoA 26-6527-153 Alc-Sub-Serv-Acct-Stats-Type
26-6527-154 Alc-Sub-Serv-Acct-Interim-Ivl
4b
2 RADIUS Python Interface PPPoE or
IPoE Session
PYTHON
module sub_svc Subscriber Service Instance
3a Data Structure
• for each subscriber service Subscriber Service
sub_svc.name
instance, populate the subscriber 4a Instance
service data structure based on the sub.svc.operation
info provided in VSA 151..154. sub.svc.acct_stats_type
Subscriber service (de-)activation
• commit the subscriber service to
sub.svc.acct_interval 4 and optional accounting
pass the subscriber service instance sub.svc.type
data structure via an internal sub.svc.type_conflict_action
tagged VSA 155 encoded as VSA Name
sub.svc.qos_override
Type-Length-Value (TLV) 26-6527-155 Alc-Sub-Serv-Internal
3b
3 Python Script
7750 SR
0950
rate-limit;<upstream_bw_in_kbps>;<downstream_bw_in_kbps>
Alc-Sub-Serv-Activate = "rate-limit;5120;30720"
To deactivate the same subscriber service and revert to the initial bandwidth, the
following VSA can be included in a RADIUS CoA message:
Alc-Sub-Serv-Deactivate = "rate-limit;5120;30720"
To deactivate a subscriber service instance, its unique name must be used. In the
example above, the name equals “rate-limit;5120;30720”.
To start an accounting session when the subscriber service instance is activated, the
following attributes can be included in the Access-Accept or CoA message:
See the Subscriber Services RADIUS VSAs section for details on RADIUS attributes.
See the Subscriber Service RADIUS Accounting section for details on subscriber
service instance accounting.
PYTHON Policy
AAA RADIUS Access-Accept Script
Access-Accept Access-Accept
26-6527-151 Alc-Sub-Serv-Activate
26-6527-153 Alc-Sub-Serv-Acct-Stats-Type 26-6527-155 Alc-Sub-Serv-Internal
26-6527-154 Alc-Sub-Serv-Acct-Interim-Ivl
CoA CoA
See the Python Script section for details on the subscriber services Python script
functions and operation.
A Python script must be configured for RADIUS Access-Accept and CoA messages;
for example:
config
python
python-script "subsvc-1" create
primary-url "ftp://user:[email protected]/./py/subsvc-1.py"
no shutdown
exit
python-policy "py-policy-subsvc-1" create
radius access-accept direction ingress script "subsvc-1"
radius change-of-authorization-request direction ingress script "subsvc-
1"
exit
exit
The Python policy must then be applied to the radius-server-policy to pass the
Access-Accept messages to the Python script and to the RADIUS server to pass the
CoA messages to the Python script. For example:
configure
router
radius-server
server "server-1" address 10.1.1.2 secret <secret> create
accept-coa
python-policy "py-policy-subsvc-1"
exit
exit
exit
aaa
radius-server-policy "aaa-server-policy-1" create
python-policy "py-policy-subsvc-1"
servers
access-algorithm round-robin
router "Base"
server 1 name "server-1"
exit
exit
exit
The RADIUS Access-Accept and CoA messages are passed to the configured
RADIUS Python scripts. As shown in Figure 141, the function of the subscriber
service Python script is to interpret the subscriber service-specific VSAs that contain
the subscriber service instance parameters and to generate a new Alc-Sub-Serv-
Internal VSA containing the information required to activate the actual subscriber
service on the PPPoE or IPoE session.
This section covers the basics to understand the functionality of a subscriber service
Python script. See the Subscriber Services Python API section for a detailed
description of the alc.sub_svc Python module containing functions and data
structures used to define and activate a subscriber service instance.
VSA Name
26-6527-151 Alc-Sub-Serv-Activate = “rate-limit;5120;30720”
26-6527-153 Alc-Sub-Serv-Acct-Stats-Type = volume-time
26-6527-154 Alc-Sub-Serv-Acct-Interim-Ivl = 86400
PYTHON
sub_svc.commit_service(service)
VSA Name
26-6527-155 Alc-Sub-Serv-Internal = 0x...
0952
The alc.sub_svc Python module contains the required functions and data structure
to commit a subscriber service, including:
In this section an example of a Python script is explained that enables the activation
or deactivation of a subscriber service.
In the example, it is assumed that only a single subscriber service is activated and/
or deactivated per RADIUS message (no tagged VSAs are used) and that only a
single Alc-Sub-Serv-Activate or Alc-Sub-Serv-Deactivate VSA is present (no
concatenation of VSAs is required).
To change the upstream root arbiter rate and downstream aggregate rate bandwidth
of an IPoE session, send the following parameters in the subscriber service activate
VSA:
rate-limit;<upstream_bw_in_kbps>;<downstream_bw_in_kbps>
During the bandwidth change, the traffic should be accounted for in a separate
accounting session.
# Python - imports
import struct
from alc import radius
from alc import sub_svc
The alc.radius module provides the API access to the RADIUS VSAs in Access-
Accept and CoA messages.
The alc.sub_svc module allows the API to activate and deactivate subscriber
services.
The struct module is a Python module used in the example to convert data obtained
from the RADIUS API as a string into Python integer values.
# Python - constants
# VSA vendor ID
ALC = 6527
# ALC Radius VSA
SUB_SERVICE_ACTIVATE = 151
SUB_SERVICE_DEACTIVATE = 152
SUB_SERVICE_ACCT_STATS_TYPE = 153
SUB_SERVICE_ACCT_INTERIM_IVL = 154
The main flow in a subscriber service Python script is to first process the subscriber
service deactivations, followed by the subscriber service activations. Optionally, the
subscriber service-specific VSAs can be removed from the RADIUS message as
they are not required for further processing in the SR OS:
# Python - main()
deactivate_services()
activate_services()
radius.attributes.clearVSA(ALC, SUB_SERVICE_ACTIVATE)
radius.attributes.clearVSA(ALC, SUB_SERVICE_DEACTIVATE)
radius.attributes.clearVSA(ALC, SUB_SERVICE_ACCT_STATS_TYPE)
radius.attributes.clearVSA(ALC, SUB_SERVICE_ACCT_INTERIM_IVL)
Both the stats-type and interim interval must be specified as integers in the
subscriber service data structure. As the RADIUS API returns an octet
string, a conversion is required. The struct.unpack() function is used for this
purpose.
- commits the subscriber service activation
# Python - activate_services()
def activate_services():
# Subscriber Service Activate VSA
value = radius.attributes.getVSA(ALC, SUB_SERVICE_ACTIVATE)
if value != '':
values = value.split(';')
if values[0] == "rate-limit":
service = []
sub_svc.add_to_service(service, sub_svc.operation, sub_svc.operation_add);
sub_svc.add_to_service(service, sub_svc.name, value);
sub_svc.add_to_service(service, sub_svc.type, 'rate-limit')
sub_svc.add_to_service(service, sub_svc.type_conflict_action, sub_svc.type_con
flict_action_keep_new)
sub_svc.add_to_service(service, sub_svc.qos_override, 'i:a:root:rate=' +
values[1])
sub_svc.add_to_service(service, sub_svc.qos_override, 'e:r:rate=' + values[2])
else:
print "WARNING - Unknown service type :", values[0]
return
# Subscriber Service Accounting VSA
stats_type = radius.attributes.getVSA(ALC, SUB_SERVICE_ACCT_STATS_TYPE)
if stats_type != '':
sub_svc.add_to_service(service, sub_svc.acct_stats_type, struct.unpack("!I", s
tats_type)[0]);
interval = radius.attributes.getVSA(ALC, SUB_SERVICE_ACCT_INTERIM_IVL)
if interval != '':
sub_svc.add_to_service(service, sub_svc.acct_interval, struct.unpack("!I", i
nterval)[0]);
# Activate the Subscriber Service
sub_svc.commit_service(service)
• The conflict action determines the behavior when multiple subscriber services of
the same type are activated for the same PPPoE or IPoE session:
- Conflict action = none
Multiple instances of the same type can be activated.
- Conflict action = keep new
Only a single subscriber service instance of the same type is allowed.
When a new subscriber service instance of the same type is activated on a
single PPPoE or IPoE session, the old instance is deactivated, and the new
subscriber service instance is activated.
- Conflict action = keep old
Only a single subscriber service instance of the same type is allowed.
When a subscriber service instance of the same type is activated on a
single PPPoE or IPoE session, the new subscriber service instance is
rejected.
• Multi-Chassis Synchronization (MCS) is not supported for subscriber services.
The subscriber service VSAs can be tagged to allow activation and deactivation of
multiple subscriber service instances with a single RADIUS Access-Accept or CoA
message.
Table 35 lists the subscriber services RADIUS VSAs. See the RADIUS Attributes
Reference Guide for a complete description of the subscriber services VSAs.
26-6527-155 Alc-Sub-Serv-Internal For internal use only. Its value is the result of
the subscriber service commit function in
Python. (sub_svc.commit_service).
sub_svc.add_to_service(service, sub_svc.acct_stats_type, 1)
The content of the volume counters when the subscriber service accounting statistics
type equals volume-time is determined by the subscriber service action. For details,
see the subscriber service sections that follow.
The volume counters for subscriber service statistics type volume-time contain the
aggregate forwarded octets and packets of the parent PPPoE or IPoE session sla-
profile instance since the start of the subscriber service.
Time
t0 t2 t4
1Mbps 2-> 4Mbps
t1 t3
1-> 2Mbps 4-> 1Mbps 0953
The sub_svc.qos_override TLV in the subscriber services Python script adds a qos-
override action. For example:
Actual values are used to populate the subscriber service data structure in this
example; typically, these values are sent as parameters in subscriber service-
specific VSAs.
The installed QoS override actions can be verified in the output of the show service
active-subscribers detail CLI command.
The volume counters for subscriber service statistics type volume-time contain the
aggregate forwarded octets and packets of the parent PPPoE or IPoE session sla-
profile instance since the start of the subscriber service.
The same PCC rule construct is used in RADIUS subscriber services to enable IP
flow-based actions and accounting.
IP flow-based accounting is one use for a subscriber service using PCC rules.
Activated by a self-service portal or as part of an Internet subscription package,
applications identified by a 5-tuple receive specific treatment, such as bandwidth
increase, expedited forwarding, or zero rating. Volume and time statistics for the
application data are available in the subscriber service RADIUS accounting session.
This is shown in Figure 143.
2
CoA
(Subscriber Service
3
with PCC Rules)
Portal
4 Internet
Services
1
PCC Rules
• Rate Limit
• Account
• FC Change
• ...
RADIUS 0954
A PCC rule is a unidirectional set of IP flows sharing a same set of actions. IPv4 and
IPv6 flows can be combined within the same PCC rule.
A PCC rule name must be unique for each rule applied on a single PPPoE or IPoE
session. For optimal PCC rule sharing, it is recommended that the same PCC rule
name be used when its content is the same (that is, the same set of flows and same
set of actions).
Supported actions include forward, drop, redirect to ip next hop, redirect to a routing
instance, HTTP redirect, forwarding class change, rate-limit, and account.
With a specified set of actions, PCC rules are instantiated in the SR OS by IP criteria
or IPv6 criteria entries in SAP ingress or SAP egress QoS polices and/or in IP or IPv6
filter entries. A PCC rule precedence value determines the relative order of different
PCC rules when inserted in the QoS or filter policy: a rule with a lower precedence
value is be applied before a rule with a higher precedence value. Rules with the same
precedence can be automatically optimized; the relative order in which they are
applied is determined by the system for optimal sharing. Rules with no precedence
are applied at the end and are also automatically optimized.
Table 37 and Table 38 provide an overview of the PCC rule actions and where they
apply.
Table 37 Subscriber Service PCC Rule Actions Resulting in QoS Policy Changes
Forwarding Class (FC) change Ingress/Egress changes the QoS forwarding class
CLI equivalent:
config>qos
sap-ingress | sap-egress <id>
create
ip-criteria | ipv6-criteria
entry <id> create
match
<5-tuple | dscp>
exit
action fc <fc>
exit
exit
Table 37 Subscriber Service PCC Rule Actions Resulting in QoS Policy Changes (Continued)
Table 37 Subscriber Service PCC Rule Actions Resulting in QoS Policy Changes (Continued)
Table 37 Subscriber Service PCC Rule Actions Resulting in QoS Policy Changes (Continued)
Table 38 Subscriber Service PCC Rule Actions Resulting in Filter Changes (Continued)
Redirect to a routing instance Ingress redirect the traffic to the specified routing
instance
CLI equivalent:
config>filter
ip-filter | ipv6-filter <id>
create
entry <id> create
match
<5-tuple | dscp>
exit
action
forward router <router-
instance>
exit
exit
exit
Table 38 Subscriber Service PCC Rule Actions Resulting in Filter Changes (Continued)
Figure 144 and Figure 145 show the actions that can be combined in a single ingress
or egress PCC rule.
INGRESS
Account / UM
redirect URL
FC change
Rate limit
Forward
Forward
supported
Drop
combinations of
PCC rule actions
FC change (3)
- -
Account / UM (3) (4)
- -
Forward
- (2) (2)
Drop - - - - - - -
Filter
redirect next-
hop or router
(2)
- -
redirect URL - - - - (2)
- -
Gate
0961
EGRESS
Account / UM
Forward
supported
Drop
combinations of
PCC rule actions
FC change (3)
-
Account / UM (3) (4)
-
Forward
-
Filter
Drop - - - - -
Gate
0962
Notes:
A PCC rule can result in one or more IPv4/IPv6 filter and/or QoS policy IPv4/IPv6
criteria entries. This is transparent to the operator.
• A PCC rule is split into IPv4 filter entries, IPv6 filter entries, SAP ingress QoS IP
or IPv6 criteria, and SAP egress QoS IP or IPv6 criteria.
• Each entry is inserted into the corresponding policy at a reserved range for
dynamic PCC rule inserts. Within the reserved range, the (optional) precedence
value for the rule is considered for the relative order of different PCC rules.
• The QoS rate-limit and account actions spawn a dynamic policer from a
reserved range in the QoS policy. A template configuration provides dynamic
policer parameters such as hierarchical policer parent, burst sizes (MBS, CBS),
statistics mode and packet byte offset. Each of the dynamic policer parameters
configured in the template can be overridden per PCC rule in the subscriber
service activation (see Table 47). A maximum of one dynamic policer is
instantiated per PCC rule. There is a maximum of 63 dynamic policers per
direction and per SLA profile instance. The output queue for PCC rule traffic
mapped in the dynamic policer is determined by a mechanism called forwarding
class inheritance: the output queue is the same queue that would be used if a
packet with the same forwarding class as the PCC rule packet was classified
using the applied QoS policy. The resulting output queue can be a local
subscriber queue (when the FC is mapped to a queue or when the FC is mapped
to a policer at egress and the policer is mapped to a local queue), a shared
queue (when the FC is mapped to a policer at ingress) or a queue-group queue
(when the FC is mapped to a policer at egress).
• Optimal policy and rule sharing is achieved by QoS and filter policy cloning and
internal PCC rule optimizations. The mechanisms are the same as for Gx-
initiated PCC rules as described the Generic Policy Sharing and Rule Sharing
and Gx Rule Ordering.
PCC rule sharing can only happen when the content is the same: identical name,
direction, precedence value, set of flows, and set of actions. PCC rules with the
same content have the same PCC rule ID.
Filter and QoS policy clones that result from PCC rule instantiation can be
recognized by a filter ID or QoS policy ID in the format 1 to 65535:P1 to 4096;
for example, filter ip 10:p3
• PCC rules can be inactive if the corresponding host type is not present. For
example, a PCC rule-based subscriber service with an IPv6 filter action can be
activated on an IPoE session while there is no IPv6 host instantiated on the
session. When the IPv6 host is later created, the PCC rule is activated.
• To install PCC rule QoS actions, a non-default ingress and egress QoS policy
with a sub-insert-shared-pccrule range configured must be associated with
the IPoE or PPPoE session (the default QoS policy cannot be modified). If a
rate-limit or account action is needed, a dynamic policer range must also be
configured. Additional dynamic policer parameters are optional and can be
overridden per PCC rule in the subscriber service activation (see Table 47).
configure qos
sap-ingress <policy-id> create
sub-insert-shared-pccrule start-entry <entry-id> count <count>
dynamic-policer
range start-entry <policer-id> count <count>
packet-byte-offset {add <add-bytes> | subtract <sub-bytes>}
mbs <size> [bytes|kilobytes]
cbs <size> [bytes|kilobytes]
parent <arbiter-name> [weight <weight-level>] [level <level>]
stat-mode <stat-mode>
exit
exit
• To install PCC rule filter actions, an IPv4 and/or IPv6 filter with sub-insert-
shared-pccrule range configured must be associated with the IPoE or PPPoE
session.
• PCC rule QoS actions result in QoS policy clones that are applied at the SLA
profile instance level. Traffic from all subscriber hosts and sessions sharing the
SLA profile instance is subject to the specified actions.
• PCC rule filter actions result in IPv4 or IPv6 filter clones that are applied at the
subscriber host level. Only traffic from the subscriber host of the same type (IPv4
or IPv6) that belongs to the PPPoE or IPoE session is subject to the specified
actions.
A PCC rule with flow match criteria that are not explicitly IPv4 or IPv6 results in both
IPv4 and IPv6 match criteria being installed; for example, destination address = any.
Filter actions are executed before QoS actions. If an IP flow is rate-limited, it should
pass the IPv4 or IPv6 filter first. Adding a QoS action rate limit to a PCC rule does
not automatically insert a corresponding forward entry in an IP filter. When needed,
this must be done explicitly by the operator with a filter forward action. For example,
an IP filter with the default action drop and several explicit forward entries is applied
to an IPoE session. A new IP flow must be rate-limited and accounted for. The PCC
rule should include match criteria for the IP flow and a QoS action rate limit, QoS
action account, and filter action forward. Without the filter action forward, the IP flow
would be dropped by the default action in the filter policy.
config>filter
ip-filter <filter-id> create
sub-insert-shared-pccrule start-entry <entry-id> count <count>
exit
ipv6-filter <filter-id> create
sub-insert-shared-pccrule start-entry <entry-id> count <count>
exit
See Bulk Changes while Gx Rules are Active for information about the parameters
that can be changed in the base filter and QoS policies when PCC rules are applied.
• A subscriber service can contain multiple PCC rules. Because a PCC rule is
unidirectional, including an ingress and an egress PCC rule enables subscriber
service accounting of bidirectional flows.
• A PCC rule can contain multiple flows. Flows in a PCC rule can be a mix of IPv4
and IPv6 flows.
• Per PCC rule dynamic policer parameters can optionally be specified. These
parameters override the dynamic-policer configuration in the sap-ingress or sap-
egress QoS policies.
subscriber-service {
name = <subsvc name>
operation = add | delete
acct-stats-type = off | volume-time | time
acct-interval = <value>
type = <string>
type-conflict-action = keep-old | keep-new | none
pcc-rule {
name = <name>
direction = ingress | egress
flow = <5-tuple> | <dscp>
flow = <5-tuple> | <dscp>
…
flow = <5-tuple> | <dscp>
action = <action>
action = <action>
…
action = <action>
precedence = <value>
policer {
parent-arbiter = <arbiter-name>
parent-level = <level>
parent-weight = <weight-level>
mbs = <bytes | default>
cbs = <bytes | default>
stat-mode = <stat-mode>
packet-byte-offset = <offset>
}
}
…
pcc-rule {
name = <name>
direction = ingress | egress
flow = <5-tuple> | <dscp>
flow = <5-tuple> | <dscp>
…
flow = <5-tuple> | <dscp>
action = <action>
action = <action>
…
action = <action>
precedence = <value>
policer {
parent-arbiter = <arbiter-name>
parent-level = <level>
parent-weight = <weight-level>
mbs = <bytes | default>
cbs = <bytes | default>
stat-mode = <stat-mode>
packet-byte-offset = <offset>
}
}
}
The sub_svc.pccrule TLV in the subscriber services Python script adds a PCC rule
to the subscriber service, as shown in the output example below:
Actual values are used to populate the subscriber service data structure in this
example; typically, these values are sent as parameters in subscriber service-
specific VSAs.
In the above subscriber service example, two PCC rules are installed, each with one
flow:
• If at least one PCC rule in the subscriber service has the QoS account action
enabled (pccrule.qos_action_account = True), then the volume counters contain
the sum of the dynamic policer forwarded octets and packets statistics of all the
PCC rules in the subscriber service with pccrule.qos_action_account = True.
• If all PCC rules in the subscriber service have the QoS account action disabled
(pccrule.qos_action_account = False), then the volume counters contain the
aggregated forwarded octets and packets of the parent PPPoE or IPoE session
SLA profile instance since the start of the subscriber service.
PCC rule-based subscriber services with QoS actions interact with the classification
and QoS forwarding mechanisms. This section describes how this affects the parent
RADIUS accounting volume counters.
For subscriber service PCC rule QoS actions that do not result in the instantiation of
a dynamic policer (such as a change of forwarding class or forward), the PCC rule
matched traffic is included in the parent accounting session volume counters. This is
shown in Figure 146, where the forwarding class is mapped to a subscriber queue,
and in Figure 147 where the forwarding class is mapped to a subscriber policer.
BE Q
1. IP Criteria | IPv6 Criteria
2. DSCP AF Q
3. PREC
4. Dot1p EF Q
5. Default-FC NC Q HQOS
BE Q
1. IP Criteria | IPv6 Criteria
2. DSCP AF Q
3. PREC
EF P
4. Dot1p
HQOS Port
5. Default-FC NC Q
Q
PCC rule
parent host/session/q-instance
accounting includes PCC rule
applies to: ingress and egress matched traffic
0956
For subscriber service PCC rule QoS actions that result in the instantiation of a
dynamic policer (such as rate-limit or account), the dynamic policer counters are not
included in the aggregate counters nor are they reported as separate detailed policer
statistics. Instead, the traffic matching the PCC rules is counted in the output queues
that correspond to the forwarding class of the packets.
• On ingress, the dynamic policer PCC rule traffic is never included in the parent
host, session, or queue instance accounting session counters. Ingress policed
traffic always uses the ingress shared policer output queues, as shown in
Figure 148.
• To include the egress dynamic policer PCC rule traffic in the parent host,
session, or queue instance accounting session counters, the dynamic policer
must use a local subscriber output queue, as shown in Figure 149.
(No FC override)
• To exclude the egress dynamic policer PCC rule traffic from the parent host,
session, or queue instance accounting session counters, the dynamic policer
must use a queue-group output queue, as shown in Figure 150. The dynamic
policer traffic inherits the policer-to-output queue mapping from the static policer
that corresponds to the forwarding class of the packet. The following SAP
egress configuration example uses the default policer output queue-group:
config>qos
sap-egress 10 create
sub-insert-shared-pccrule start-entry 200 count 10
dynamic-policer
range start-entry 10 count 10
exit
policer 1 create
exit
fc be create
policer 1
exit
exit
If a packet is classified as FC = Best Effort (BE) and matches a PCC rule with
rate-limit action only (no FC change), the traffic hits the PCC rule dynamic
policer and then the queue-group queue associated with policer 1 (the static
policer for FC = BE).
• A special case occurs when, at egress, the forwarding class maps to a static
policer and then to a local subscriber queue. Traffic for that forwarding class
hitting a dynamic policer uses the local subscriber queue as the output queue.
In this case, the dynamic policer PCC rule traffic is included in the parent host,
sessions or queue instance accounting session counters. This is shown in
Figure 151.
BE Q
1. IP Criteria | IPv6 criteria
2. DSCP AF Q
3. PREC
4. Dot1p EF P Q
5. Default-FC NC Q HQOS
PCC rule P
Pcc rule filter action redirect to nexthop_v4/v6 value must be a valid IPv4/v6 address
Pcc rule filter action http redirect value is not a valid URL
Pcc rule filter action http redirect value too long (> 255)
Pcc rule flow src/dst_ip match value is not a valid IP address: <ipv4-address>|<ipv6-
address>|any
Pcc rule flow port match type must be a string: <port>[-<port>] with port [0..65535]
Pcc rule flow protocol match value must be less than 255
ESM Failures
The PCC rule redirect URL has a maximum of 255 displayable characters.
All flows in a PCC rule must have the same direction (ingress or egress).
A flow in a PCC rule cannot have a mix of IPv4 and IPv6 addresses (for example src-ip
and dst-ip).
ESM—Processing Failures
If a PCC rule contains a direction-specific action (such as a redirect), it must contain at least
one flow in that direction.
If a PCC rule contains only IPv4 actions (such as a redirect to an IPv4 next hop), it must
contain at least one IPv4 flow. This also applies to IPv6.
The combinations of PCC rule actions must be supported (see Figure 144 and Figure 145).
There must be at least one flow and at least one action per PCC rule.
ESM Failures
There is a maximum of 64 PCC rules per host or session.
There are not enough filter or QoS resources to create policy clones or apply them to the
host or session.
The filter or QoS policy clone cannot be created (for example, the redirect service does not
exist).
Simultaneous provisioning of PCC rules from Gx and RADIUS is operationally blocked per
subscriber session/host.
sub_svc.add_to_service (svc, sub_svc TLV, value) Appends a TLV to the service list. The service list
describes the subscriber service and should be passed to
the sub_svc.commit_service() to activate or deactivate
the subscriber service.
Parameters:
svc (type = list): service list that describes the subscriber
service. sub_svc TLVs are appended to this list with the
sub_svc.add_to_service() function.
sub_svc TLV (type int): TLV that is appended to the
service list
value (type as defined for the sub_svc TLV): the value of
the sub_svc TLV that is appended to the service list
sub_svc.commit_service (svc) Creates the required internal VSAs based on the TLVs
provided in the svc list.
Parameters:
svc (type = list): service list that describes the subscriber
service. sub_svc TLVs are appended to this list with the
sub_svc.add_to_service() function. The service list
should be passed to sub_svc.commit_service() to activate
or deactivate the subscriber service.
Default operation_del
Default Off
Default type_conflict_action_none
sub_svc.pccrule.add_to_pccrule (pccrule, Appends a PCC rule TLV such as name, precedence, flow, or
pccrule TLV, value) action to the PCC rule list. The PCC rule list describes the
PCC rule and can be added to a subscriber service with the
sub_svc.add_to_service() function.
Parameters:
pccrule (type = list): PCC rule list that describes the PCC rule.
PCC rule TLVs are appended to this list with the
sub_svc.pccrule.add_to_pccrule() function.
pccrule TLV (type int): PCC rule TLV that is appended to the
PCC rule list
value (type as defined for the PCC rule TLV): the value of the
PCC rule TLV that is appended to the PCC rule list
pccrule.precedence O Purpose Specifies the precedence value for the PCC rule. The
(Integer) precedence defines a relative order of the different PCC
rules: a rule with a lower precedence value is applied
before a rule with a higher precedence value.
Rules with the same precedence and rules without
precedence can be automatically optimized; the relative
order in which they are applied is determined by the
system for optimal sharing.
Value 0 to 65535
direction_egress (2)
Default n/a
pccrule.flow M Purpose Adds a flow to the PCC rule. At least one flow must be
(list) added to a PCC rule. Multiple flow TLVs can be added to
a PCC rule.
Value A flow list describing the flow with flow TLVs such as
dscp, protocol, src-ip, dst-ip, src-port, and dts-port
Flow TLVs are appended to the flow list with the
sub_svc.flow.add_to_flow() function.
Default False
Value String with fixed format forwarding class name: “be”, “l2”,
“af”, “l1”, “h2”, “ef”, “h1” or “nc”
Default n/a
Default n/a
Default None
Default n/a
Default n/a
pccrule.filter_action_ O (1) Purpose PCC rule action: redirect to a next-hop IPv4 address
redirect_to_nexthop_v Can be applied on ingress only
4 Results in an IPv4 filter entry
(string) CLI equivalent:
entry 10 create
match
...
exit
action
forward next-hop <ip-address>
exit
exit
Default n/a
Default None
Default n/a
Value service-id
Default n/a
Default n/a
Default None
pccrule.policer_parent O Purpose Specifies the dynamic policer parent level for this PCC
_level rule.
(Integer) Overrides the dynamic policer value configured in the
sap-ingress or sap-egress QoS policy.
Value 1 to 8
Default None
pccrule.policer_parent O Purpose Specifies the dynamic policer parent weight for this PCC
_weight rule.
(Integer) Overrides the dynamic policer value configured in the
sap-ingress or sap-egress QoS policy.
Value 1 to 100
Default None
pccrule.policer_mbs O Purpose Specifies the dynamic policer MBS value in bytes or reset
(Integer) to the default MBS value for this PCC rule.
Overrides the dynamic policer value configured in the
sap-ingress or sap-egress QoS policy.
Value 0 to 16777216
-1 sets the default MBS
Default None
Value 0 to16777216
-1 sets the default CBS
Default None
Value Note that integer values are mapped to each of the stats-
mode.
ingress:
0 = pccrule.ingress_stat_mode_no_stats
1 = pccrule.ingress_stat_mode_minimal
2 = pccrule.ingress_stat_mode_offered_profile_no_cir
3 = pccrule.ingress_stat_mode_offered_total_cir
4 = pccrule.ingress_stat_mode_offered_priority_no_cir
5 = pccrule.ingress_stat_mode_offered_profile_cir
6 = pccrule.ingress_stat_mode_offered_priority_cir
7=
pccrule.ingress_stat_mode_offered_limited_profile_cir
8=
pccrule.ingress_stat_mode_offered_profile_capped_cir
9=
pccrule.ingress_stat_mode_offered_limited_capped_cir
egress:
0 = pccrule.egress_stat_mode_no_stats
1 = pccrule.egress_stat_mode_minimal
2 = pccrule.egress_stat_mode_offered_profile_no_cir
3 = pccrule.egress_stat_mode_offered_total_cir
4 = pccrule.egress_stat_mode_offered_profile_cir
5=
pccrule.egress_stat_mode_offered_limited_capped_cir
6=
pccrule.egress_stat_mode_offered_profile_capped_cir
8 = pccrule.egress_stat_mode_offered_total_cir_exceed
9=
pccrule.egress_stat_mode_offered_four_profile_no_cir
10 =
pccrule.egress_stat_mode_offered_total_cir_four_profil
e
Default None
Default None
Notes:
• (1) At least one PCC rule action must be specified.
• M=Mandatory, O=Optional
sub_svc.flow.add_to_flow (flow, flow Appends a flow TLV such as dscp, protocol, src-ip, dst-ip, src-port,
TLV, value) or dst-port to the flow list. The flow list defines matching criteria for
an IP flow and can be added to a PCC rule with the
sub_svc.pccrule.add_to_pccrule() function.
Parameters:
flow (type = list): list containing the match criteria (DSP, 5-tuple) that
describes an IP flow. Flow TLVs are appended to this list with the
sub_svc.flow.add_to_flow() function. The flow is added to a PCC rule
with the sub_svc.pccrule.add_to_pccrule() function.
flow TLV (type int): Flow TLV that is appended to the flow list.
value (type as defined for the flow TLV): the value of the flow TLV
that is appended to the flow list
Default n/a
Default n/a
Default any
Default n/a
Default any
Default n/a
To display the active subscriber services in the system, use the show service sub-
services CLI command. The sub-service-name filter is a longest match.
Sample output:
QoS-override
ingress arbiter "root" rate 5120
QoS-override
egress aggregate rate limit 30720
-------------------------------------------------------------------------------
number of subscriber services found: 1
===============================================================================
To display the active PCC rules in the system, use the show service active-
subscribers pcc-rule CLI command. A PCC rule can be inactive when, for example,
a PCC rule with filter actions on IPv6 flows is activated on an IPv4single-stack
PPPoE or IPoE session.
Sample output:
FC change : -
Account : Enabled
-------------------------------------------------------------------------------
Flows
-------------------------------------------------------------------------------
Src. IP : any Src. Port: -
Dst. IP : 172.16.1.1/32 Dst. Port: -
Protocol : - DSCP : -
-------------------------------------------------------------------------------
Src. IP : any Src. Port: -
Dst. IP : 2001:db8:aaa:1::1/128 Dst. Port: -
Protocol : - DSCP : -
-------------------------------------------------------------------------------
===============================================================================
PCC rule name : rule-2
PCC rule id : 20
Monitoring key : -
Flow status : Enabled
Nbr of Flows : 2 (egress)
HTTP-Redirect : -
Next-Hop Redir. IPv4 : -
Next-Hop Redir. IPv6 : -
QoS Ingr. CIR/PIR : - / -
QoS Egr. CIR/PIR : - / 5000 kbps
FC change : -
Account : Enabled
-------------------------------------------------------------------------------
Flows
-------------------------------------------------------------------------------
Src. IP : 172.16.1.1/32 Src. Port: -
Dst. IP : any Dst. Port: -
Protocol : - DSCP : -
-------------------------------------------------------------------------------
Src. IP : 2001:db8:aaa:1::1/128 Src. Port: -
Dst. IP : any Dst. Port: -
Protocol : - DSCP : -
-------------------------------------------------------------------------------
===============================================================================
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Use the following alternative command to check the PCC rules in the system:
The details of the cloned QoS and filter policies as a result of PCC rule activation can
be displayed with the following show commands:
debug
router "Base"
radius
packet-type authentication accounting coa
detail-level high
exit
exit
python
python-script "subsvc-1"
script-all-info
exit
exit
exit
For information on resource monitoring, see PCC Rules and Capacity Planning and
PCC Rule Scaling Example.
The following CLI command provides an overview of the resource usage per line
card, such as the number of ACL and ACL QoS entries, Filters, QoS policies,
dynamic policers, and QoS overrides:
These resource counters are available in SNMP and can be used in RMON to trigger
threshold crossing alarms; for example:
configure system
thresholds
rmon
alarm 1 variable-
oid tFPResIngIPv6AclEntryAlloc.1.1.1 interval 10 rising-event 1 rising-
threshold 25000 falling-event 2 falling-threshold 24000
event 1 description "Ingress IPv6 ACL Entries too high"
event 2 description "Ingress IPv6 ACL Entries - below limit"
exit
The summary output of the show subscriber-mgmt pcc-rule command lists the
number of active PCC rules and the number of active combinations:
Starting in Release 13.0R4, if an IP conflict occurs on the same SAP, then by default
the new RG (MAC) immediately overrides the DHCP lease of the old device. This is
known as lease-override. This is applicable to DHCP relay and proxy for both IPv4
and IPv6 hosts. Prior to Release 13.0.R4, lease-override only occurred for DHCPv4
relay. The lease-override is performed only when an IP conflict occurs within the
same SAP.
The other option is to use trigger SHCV to check the connectivity status of the old RG
before removing it and its lease. This is known as the ip-conflict-triggered SHCV
under the SHCV policy. The SHCV is sent only when the BNG detects an IP address
conflict on DHCP discovery. If the host does not respond within the configured
timeout, both the host and lease are removed from the BNG. The new RG is required
to perform a subsequent DHCP discovery or request to install a host. SHCV can help
prevent malicious RGs from spoofing another RG IP address. Trigger SHCV for IP-
conflict is available for DHCPv4/v6 relay and proxy, as well as ARP hosts. The
following table specifies when the SHCV is sent for IP-conflict.
It is also possible that new RGs are denied service as a consequence of a set of host
limits against the subscriber including sla-profile host-limits and session-limits, sub-
profile host-limits and session-limits, ipoe session-limit, and ipoe sap-session limits.
For example, setting a host limit of overall 1 can ensure that each home only takes
one IP address. As mentioned before, RGs do not inform the BNG of a disconnect.
If SHCV is enabled, it might take some time before the BNG is informed of the
disconnect. Therefore, when a new RG connects to the BNG, the BNG performs a
host-limit check (if configured) against the subscriber. If the old host still has an entry
on the BNG and there is a host-limit of overall 1, the new RG is denied an IP address
and/or prefix assignment because it has exceeded the host limit. A trigger SHCV,
“host-limit-exceeded” inside the SHCV policy can be configured against a group
interface. This SHCV is triggered when an over limit is detected. If the existing host
registered on the BNG does not respond within the configured timeout, both the host
and its lease are removed from the BNG. The SHCV can only remove hosts from the
BNG and the new RG is still required to perform a subsequent DHCP discoveries or
requests to obtain an IP address.
By providing lease-override and various SHCV triggers in the SHCV policy, service
providers have a variety of options to allow subscribers to perform quick and
seamless RG replacements.
It is possible to use the host-connectivity check without the SHCV policy. The main
function of the host-connectivity check is for periodic check. The trigger functions are
performed through the SHCV policy.
• DHCPv4 support:
- dropped protocol messages (host setup/renew)
- protocol timeouts
• PPPoEv4 support:
- dropped protocol messages
- traps
All subscriber problems are first stored in a main circular buffer. The main circular
buffer is then fed into smaller circular buffers, organized by MAC addresses. When
the buffer is full, the first circular buffer purges the oldest message to make room for
the newest message. The smaller circular buffers (one per MAC address) store a
limited number of messages per MAC. Again, the smaller buffer deletes the oldest to
make room for the newest. The circular buffer, per MAC, prevents one device from
holding all the error messages in the buffer. The main circular buffer can hold 5,000
errors in total, while the smaller buffer can hold 10 log entries per MAC. The circular
buffer supports CPM3 and higher.
The show command allows sorting by MAC, subscriber SAP, SDP, and unknown-
origin (unknown SAP or SDP). The show command allows the input of a specific
MAC, SAP, or SDP to directly search for particular subscriber issues or problems.
The circular buffer only logs drop reasons for DHCPv4 and PPPoEv4. Non-error
reasons are never logged; for example, a drop due to being in SRRP standby is not
logged. The circular buffer has a timestamp associated with each error and the errors
are listed beginning with the most recent. Error logs are lost on a HA switchover, and
persistency is not supported. There is no throttling mechanism for the same errors;
it is possible to fill the circular buffer with the same error message from different MAC
addresses.
The accumulated statistics policy supports up to four ingress and four egress entries.
For queue statistics, v4-v6 mode is not supported, where v4 and v6 statistics are
always aggregated. For policer statistics, only min-mode is supported.
When a single subscriber has a list of bridge hosts, all hosts are forced to use the
same statistics policy. If hosts use a different SLA profile and the operator wants to
collect the statistics for all hosts, the statistics policy must encompass all queues and
policers for various SLA profiles. If there are multiple SLA profile instances for the
same subscriber, the statistics are summed up for each instance on a per policer or
queue basis. These statistics are not exchanged between MCS peers. Therefore, for
dual-homed hosts, the statistics need to be gathered from all the nodes and then
summed up. If a queue or a policer is missing from the accumulated statistics policy
in the current subscriber session and offline statistics exist for that entity from
previous sessions, these offline stats are lost when the current subscriber session
ends.
Cumulative statistics for a subscriber are not persistent; they are only stored in
memory and are lost after node reboot (the statistics start at zero).
If resources for capturing offline statistics are full, a trap is generated in log 99 to warn
the operator. The command show subscriber-mgmt status system shows the
number of subscribers using these accumulated statistics and a flag in this command
shows whether the usage is at its peak value.
When the active subscriber has an accumulated statistics policy, the subscriber’s
offline statistics can be deleted using the following command.
To remove the offline statistics for all active subscribers that are no longer associated
with an accumulated statistics policy, the following command can be used.
To remove the offline statistics for a group of active subscribers that is no longer
associated to an accumulated statistics policy and that has a defined subscriber
profile (for example, if the accumulated statistics policy has been removed from the
subscriber profile), the following command can be used.
It is also possible to remove the offline statistics for an inactive (offline) subscriber.
To remove offline statistics for all inactive subscribers, use the following command.
To remove offline statistics for a specific inactive subscriber, use the following
command.
Figure 152 shows a sample Hybrid Access deployment with a BNG-based HAG.
GTP GTP
(S1-MME) (S11)
MME
GTP
LTE eNoveB (S1-U) Internet
BNG
SGW
PGW
RG
PPPoX
xDSL
MSAN
sw0204
Figure 153 shows a sample Hybrid Access deployment with a PGW-based HAG.
GTP GTP
(S1-MME) (S11)
SGW PGW/HAG
GTP GTP
LTE eNodeB (S1-U) (S5)
Internet
RG
GTP
xDSL (S2a)
PPPoX
MSAN
BNG 1039
9.27.1 Setup
During normal authentication, access connections can indicate they are part of a
common bonding context by specifying a bonding identifier. When the first connect
is set up, an additional authentication phase is started for the bonding context itself.
Figure 154 shows RADIUS-based authentication for bonding of an IPoE and GTP
access connection. For simplicity, all access nodes, such as the residential gateway,
MSAN, eNodeB, and MME have been identified as a single entity.
sw0205
All address assignments and Layer 3 parameters are shared between the access
connections and are therefore handled in the bonding context. The system supports
either Local Address Assignment or AAA-provisioned IP addresses. Access
connections cannot use any DHCPv6 relay or client mechanisms.
After the setup is complete, ESM subscriber resources are created for each context
as follows.
• a unique subscriber with a single internal IPoE session to represent the bonding
context
This is the main context for functionality, including QoS, filters, and accounting.
This subscriber cannot be reused for any other hosts, regardless if they are
bonding or not.
• a subscriber per access connection with one or more hosts as needed,
depending on the access type
This subscriber must be distinct from the bonding subscriber. Other non-bonded
hosts or sessions may be present under the same subscriber. A subset of ESM
features (for example, QoS, filters, and accounting) are also available in this
context; however, it is recommended that the most of the feature be configured
in the bonding context.
All access and bonding ESM contexts need to be present in distinct VRFs. The
bonding context must be created in a special group interface of type bonding. This
group interface is not linked to any SAPs, however, an FPE construct ensures the
link between the access and bonding context.
The initial hash weights can also be dynamically adapted based on the load on the
primary connection. The IOM periodically measures how much traffic is sent over the
primary connection, comparing it to a predefined saturation rate. When the
connection is saturated, the hash weights automatically change to send more traffic
over the alternate link. Similarly, if the total rate of traffic decreases, the hashing
weights change to send more traffic over the primary connection.
When only a single connection is active, all traffic is sent to this connection,
regardless of hashing weights or filters.
If one of the two access connections is idle, then the system activates this connection
prior to changing hashing weights. This sequence allows the system to avoid
overflowing the packet buffer of the idle connection. For example, for an idle S11
GTP connection, the system reactivates the connection through a network-triggered
service request before changing weights.
9.27.3 QoS
Regular ESM QoS is supported in both the access and bonding contexts; however,
there is no direct feedback mechanism between the two contexts. Therefore, if an
access connection drops a packet, it is not reflected in bonding statistics, nor does it
cause backpressure on the bonding QoS algorithm.
When traffic passes over the FPE from the bonding context to the access context or
from the access context to the bonding context, the system keeps the traffic
classification and the in- and out-profile markings. Although this occurs
automatically, bonding subscriber policies for ingress and egress should consider
the following recommendations.
• Enable de-mark for access egress and map each FC to the dot1p as defined in
Table 51, thus ensuring that the same classification is used in the access
connection context.
• Perform classification for access ingress based on dot1p as defined in Table 51
and enable in-profile and de-1-out-profile for each FC, thus ensuring the same
classification is used as for the access connection context. A different
classification scheme can be used if required, for example, based on DSCP or
IP criteria.
FC dot1p
be 0
l2 1
af 2
l1 3
h2 4
ef 5
h1 6
FC dot1p
nc 7
9.27.4 Multicast
Multicast replication is supported in context of the access connections. By default,
multicast streams are replicated in the connection where the corresponding IGMP/
MLD join is received; however, this can be overridden to always force a specific
connection.
When one connection fails, multicast replication automatically sets up in the alternate
connection and does not require a new IGMP/MLD packet to arrive.
1/1/16
Satellite
Host Node Node
Uplink Satellite
Links
sw0791
• A/S uplinks can be on the same forwarding path (FP) or forwarding complex or
on a different FP. An FP refers to a set of chipsets on a line card used to
simultaneously forward paired upstream and downstream traffic.
• Although a pair of uplinks can be active or standby for the same set of ports, both
uplinks can be active for a set of different ports. For example:
Figure 156 displays an example of an SR OS host, satellite node and access node.
Figure 157 displays an example of an SR OS host, satellite node, and access node.
1
k 2
lin
Up nk
e
ctiv U pli
A by Access
SR OS Host
nd Node
A Sta
L
A
G
B St
an
db
Ac yU
tiv pli
e nk
Up
lin
k
3
4
Satellite
Node sw0793
9.28.3 QoS
Queues and policers in ESM are created on a per SLA profile instance in the host
node. A subscriber host resides in a host node on a SAP that is associated with a
logical port (mapped to a user port on the satellite node) which is then associated
with the physical uplink.
Buffer pools are the only QoS configurations that are created on a per-physical uplink
basis.
9.29.1 Overview
SR OS supports synchronization of usage counters that can be reported through
RADIUS accounting in a dual-homed BNG scenario.
The active (SRRP master state) node keeps the total number of statistics that are
reported. The active node synchronizes those statistics in regular intervals with MCS
to the standby node. This way, the main copy of the total statistics is maintained on
both nodes and failure cases of link, node, and so on, these statistics can be
recovered from the surviving node.
If there are multiple RADIUS accounting policies in a subscriber profile, the minimum
value of all the configured MCS intervals in these RADIUS accounting policies is
used for usage counter synchronization.
ACCT-INPUT-GIGAWORDS [52]
ACCT-OUTPUT-GIGAWORDS [53]
Alc-IPv6-Acct-Input-Octets [26-6527-195]
Alc-IPv6-Acct-Output-Octets [26-6527-198]
Alc-IPv6-Acct-Input-Gigawords [26-6527-196]
Alc-IPv6-Acct-Output-Gigawords [26-6527-199]
The following accounting attributes are synchronized per queue and policer:
Alc-Acct-I-Inprof-Octets-64 [26-6527-19]
Alc-Acct-I-Outprof-Octets-64 [26-6527-20]
Alc-Acct-O-Inprof-Octets-64 [26-6527-21]
Alc-Acct-O-Outprof-Octets-64 [26-6527-22]
• Node reboot — Since the main copy of the stats is maintained on both nodes,
the stats are recovered from the remaining node.
• Split brain — A split brain scenario should never occur. If it does, the statistics
are reported from both nodes (both in SRRP master state). Once the MCS
recovers, the statistics are re-synchronized at the regular MCS intervals.
The active node accepts updates received from the other node only when the
value of the counter is larger than the local total.
• SRRP switchovers— If a host is installed by MCS, and a SRRP switchover
occurs before the statistics are retrieved from the active node, the RADIUS
accounting messages going out before the statistics are retrieved have
unsynced statistics (statistics on a time the node did not yet receive an answer
from its peer and is still requesting statistics).
After retrieving the stats, retrieved and unsynced counter values are compared
and the higher counter value is chosen for accounting.