SAE Support for Dual-Stack Configuration
JunosE Dual-Stack Support
JunosE supports configuration of Internet protocol versions—IPv4 and IPv6—on a single interface. This creates two IP layer interfaces (IPv4 and IPv6), known as dual-stack, that run and report independently.
To support dual-stack configuration, the functionality of the SAE is configured to create a single subscriber session for a set of IP interfaces. All services activated for a subscriber session impacts the related interfaces. For example, when both IPv4 and IPv6 interfaces exist for a subscriber session, a service activation installs policies on both the interfaces.
Each dual-stack interface consumes about twice the memory resources than a single interface. The total number of subscriber sessions supported by the SAE for dual-stack interfaces would be cut by half.
For C3000, the maximum number of dual-stack subscriber sessions is 150,000 (using two active services per subscriber).
For C5000, the maximum number of dual-stack subscriber sessions is 500,000 (using two active services per subscriber).
The performance in login/logout rate, as well as service activation/deactivation rate of a dual-stack interface would be about 50% when compared to the performance of a single-stack interface.
Handling of Interface-Up Notification
In dual-stack configuration, the interfaces are reported by the router independently. The router sends two interface-up notifications that are tied together by their interface name. The default policies for a subscriber session are then applied independently on these interfaces.
The dual-stack interface-up notification sequence is as follows:
When the router receives the first IP interface-up request, it acquires a lock on the interface.
For example, if an IPv4 interface is reported first, the router acquires a lock for the interface name and holds on to it until the request is processed.
The router keeps track of the underlying interfaces (IPv4 and IPv6) and communicates with the SAE to create appropriate policies for each interface.
The router processes the IP interface-up request, creates the user session, and installs default policies.
If default policies are not defined, processing for the interface stops and the interface remains unmanaged.
The activate-on-login service session provisions the relevant policies (IPv4 and IPv6) for the interface.
The router releases the lock on the IP interface after the request has been processed.
When the router receives the second IP interface-up request, it attempts to acquire a lock on the IP interface.
If the processing for the first IP interface request is not completed, the router handler thread blocks the second IP interface-up notification until the lock is released for the first IP interface.
The router processes the second interface-up request and installs the default policies.
The router checks for the user session that is currently associated with the interface name.
If a user session already exists, the request is handled in the similar way to an update request and a relogin is triggered. If the relogin does not result in the termination of the existing user session, all active service sessions are notified of the modification.
The activate-on-login service session provisions the relevant policies on the second IP interface.
The router releases the lock on the second IP interface after the request has been processed.
Handling of Interface-Up Notification with Delay Timer
The delay timer (dual-stack-delay) is configured to reduce the number of interface-up notifications. This is useful if most of the interfaces are expected to be dual-stack interfaces because it reduces the overhead of relogin and update plug-in events.
The dual-stack-delay attribute is not enabled by default.
The sequence of interface-up notifications with delay timer is as follows:
When the router receives the first IP interface-up request, it processes the request and installs the default policies.
The router creates an IP interface context that represents the Common Open Policy Service (COPS) object.
The IP interface context schedules a timer and suspends further processing. This postpones the creation of user sessions.
After provisioning the default policies on the second IP interface, the IP interface context cancels the timer for the first IP interface.
The user session is created for the dual-stack interface.
The activate-on-login service provisions the service policies that are applied to both interfaces of the dual-stack.
If the first IP interface request is not part of a dual-stack interface, then the creation of the user session is delayed until the timer expires. This causes a delay in the login rate for a single-stack interface.
If the second IP interface request is received after the expiry of the delay timer, the user session is created and a relogin is triggered and events are updated.
Handling of Interface-Down Notification
The sequence of interface-down notifications for dual-stack configuration is as follows:
When the first IP Interface begins to shut down, the router sends a COPS delete request (DRQ) message.
The router stores final accounting for all active policies of the first IP interface to the associated IP interface context and notifies the SAE that the interface is down.
Because the IP interface is also associated with a second IP interface context, no further action is triggered.
The router sends final accounting for all active polices of the second IP interface to the associated IP interface context.
The router notifies the SAE that the second IP interface is down.
The router driver initiates the logout of the subscriber session because both the interfaces are down.
The subscriber session deactivates all active services and the service session removes the installed policies.
After the subscriber session is logged out, the interface contexts for IPv4 and IPv6 are discarded.
The router driver returns the accounting data for the individual policies.
The router keeps track of the underlying interfaces and communicates with the policy engine to create the appropriate policies for each interface. The service session provisions the relevant policies (IPv4 and IPv6) for the interface.
When the interface is down, the router notifies the SAE and deactivates the service session. The service session passes the stored provisioning sets (IPv4 and IPv6) to the router driver. The router driver removes the policies and returns the accounting data for the individual policies. Accounting data for services contains the sum of IPv4 and IPv6 counters.
Junos-ise Dual-Stack Support
Dual-stack support for JSRC allows handling of both IPv4 and IPv6 families on a single subscriber session with the following features:
Supports activations and deactivations of individual families. IP addresses are updated on the single user session accordingly.
Provides separate or aggregate accounting support for each family or both families correspondingly.
Supports backward compatibility with the older MX versions that do not support dual-stack.
We recommend having dynamic-profiles with both inet and inet6 families.
The SRC software pushes the dynamic-profile name to MX Series router. MX Series router maintains the policy for inet and inet6 families separately and activates or deactivates the policy for the corresponding family.
There is no separate provisioning for the second family activation.
Handling of First Family Activation
The first family activation sequence is as follows:
If either IPv4 or IPv6 family becomes active on the MX Series router, a provisioning AAR is populated with the IP addresses of the families that are active.
For IPv4 family, Framed-Ip-Address or Framed-Ip-Netmask is populated.
For IPv6 family, Framed-Ipv6-Address/Framed-Ipv6-Netmask or Framed-Ipv6-Prefix or Juniper-Ipv6-Ndra-Prefix is populated.
A user session is created with the IP addresses reported in AAR.
The SRC software provisions default and service policies that are applicable to both the families, that is, even for a single family reported, policy provisioning is done for both IPv4 and IPv6 families.
There is a possibility of both families being active on the MX Series router at the same instance and reported through a single provisioning AAR. For this instance, a user session is created with both IPv4 and IPv6 addresses reported in AAR.
The SRC software considers the following priority for IPv6 address population:
Framed-IPv6-Address and Framed-IPv6-Netmask
Framed-IP-Address and Framed-IP-Netmask (for backward compatibility)
If ignore-framed-ipv6-netmask is configured, the prefix length of ipv6 address is considered as 128.
Handling of Second Family Activation
The second family activation sequence is as follows:
If the second family becomes active on the MX Series router, an notification AAR (Family Activation) is reported with the IP address of the family that became active.
Based on the session ID, the existing user session is looked up and updated with the new IP address reported.
A user interim is sent to the northbound plug-ins to notify the user session update.
There is no separate provisioning for the second family activation, as the provisioning is done for both families on first family activation itself.
Handling of Family Deactivation
The single family deactivation sequence is as follows:
If a family becomes inactive on the MX Series router, a notification AAR (Family Deactivation) is reported with the IP address of the family that is deactivated.
Based on the session ID, the existing user session is looked up and updated to remove the IP address details of the family that is deactivated.
A user interim is sent to the northbound plug-ins to notify the user session update.
For both automatically-on-login and manual service activation, irrespective of which family is active, the policies are provisioned for both the families.
Service is deactivated either manually or when the subscriber session terminates. The associated provisioning set is removed. There are no changes in the provisioning set, if a single family is deactivated.
ACR message has capabilities of reporting both IPv4 and IPv6 accounting attributes.
When the MX Series router sends separate accounting for each of the families, the SRC software either aggregates or sends individual accounting data to the plug-ins based on the aggregate-accounting flag configuration.
For EJB adapter plug-in, the accounting statistics are always aggregated.
If one of the families becomes inactive, the MX Series router sends the last updated accounting counters for the family that became inactive in the future interims. When the family becomes active again, the interim is reported from the last updated interim values.
If dynamic-profile in MX Series router has either one of the inet or inet6 policies and if the corresponding family gets deactivated, MX Series router triggers an ACR-Stop for the service. This results in deactivation of that service in the SRC software. As the SRC software does not re-provision the service when the family gets re-activated, we recommend to have dynamic-profiles with both inet and inet6 families at the MX Series router end.
The framedIpv6Prefix and delegatedIpv6Prefix attributes are added to the subscriber object and can be queried through the SAEAccess API module.
The framedIpv6Prefix attribute contains the IPv6 prefix for the subscriber.
framedIpv6Prefix is available for JunosE (COPS-PR), Junos OS (JSRC), as well as AAA (COA).
Using the delegatedIpv6Prefix attribute, the NAS can receive a set of IPv6 prefixes that are delegated to subscribers.
An IPv6 subscriber can be identified through multiple prefixes by using the delegatedIpv6Prefix attribute together with the framedIpv6Prefix attribute.
delegatedIpv6Prefix is available for Junos OS (JSRC), AAA (COA), and DHCPv6 subscribers on the JunosE router.
Separate Ipv6 accounting attributes are added to the service session and the corresponding support is available only for Junos OS (JSRC).
SAEAccess API Plug-in Attributes
The SAEAccess API plug-in is extended to support the following attributes:
PA_FRAMED_IPV6_PREFIX—An octet string formatted as specified in RFC3162. The first octet is 0, the second octet contains the length of the prefix in bits (1–128), and the following octet contains the actual prefix.
PA_DELEGATED_IPV6_PREFIX—An octet string formatted as specified in RFC4818. The first octet is 0, the second octet contains the length of the prefix in bits (1–128), and the following octet contains the actual prefix.
PA_USER_IP_MASK—Number of bits in the subscriber address (PA_USER_INET_ADDRESS). This attribute is available both for IPv4 and IPv6 addresses, if the underlying router driver provides the value, which is presently the case for JunosE (COPS-PR), Junos OS (JSRC), and AAA (COA).
For dual-stack interfaces, the PA_USER_INET_ADDRESS attribute contains the IPv4 address of the subscriber, whereas PA_FRAMED_IPV6_PREFIX contains the IPv6 address prefix.
For single-stack interfaces, the PA_USER_INET_ADDRESS attribute contains either the IPv4 or IPv6 address depending on the address family assigned to the subscriber.
PA_IPV6_IN_OCTETS, PA_IPV6_OUT_OCTETS, PA_IPV6_IN_PACKETS, PA_IPV6_OUT_PACKETS, PA_IPV6_TOTAL_OCTETS—Accounting attributes to handle IPv6 accounting data, which is presently supported on Junos OS (JSRC) in a dual-stack scenario.
Subscriber Session Lookup
Subscribers are identified by the set of IPv6 prefixes defined by the device driver. If both framedIpv6Prefix and delegatedIpv6Prefix are present for a subscriber session, then any IPv6 address that matches any one of the prefixes identifies the subscriber session.
For example, a subscriber session is reported by a device driver with the framedIpv6Prefix = 2001:db8:1:1::/64 and delegatedIpv6Prefix = 2001:db8:2:2::/64 attributes. Any IP address starting with one of these prefixes identifies the subscriber session (2001:db8:1:1:0:1:2:3, 2001:db8:2:2:4:3:2:1, and so on).