This section is only applicable when enabling IPoE sessions on a group interface with active subscriber hosts. When there are no active subscriber hosts on a group interface, there is no need for a migration. Use one of the following CLI commands to determine if there are active hosts on a group interface:
Check the number of subscriber hosts on a group interface: # show service id <service-id> subscriber-hosts detail | match <group-int-name> | count
DHCPv6 IA-PDs modeled as a managed route are not counted with this command.
Check the number of IP stacks (client types) attached on a group interface. # tools dump router <router-instance> ipoe-session migration interface <group-int-name>
The number of active IP stacks (client types) on the group interface are listed per type whether they are associated with an IPoE session.
DHCPv6 IA-PDs modeled as a managed route are also counted in the DHCPv6 type counter.
Check the number of DHCPv4 leases, DHCPv6 leases, and SLAAC hosts on the group interface that are not attached to a session: # show service id <service-id> dhcp4 lease-state interface <group-int-name> session none # show service id <service-id> dhcp6 lease-state interface <group-int-name> session none # show service id <service-id> slaac host interface <group-int-name> session none
DHCPv6 IA-PDs modeled as a managed route are also counted in the DHCPv6 lease state counter.
By default, IPoE sessions are disabled on a group interface (ipoe-session shutdown). Enabling IPoE sessions on a group interface with active subscriber hosts starts a migration process and should be planned carefully to allow a seamless migration.
A migration is required because of the nature of IPoE sessions: a single authentication is performed for all hosts (IP stacks) of a dual-stack end device. All hosts (IP stacks) in an IPoE session share the same MAC address, SAP, and optionally Circuit-ID / Interface-ID or Remote-ID which are configured as the session-key in the ipoe-session-policy. To determine if hosts (IP stacks) belong to a single session, a new trigger packet is required to obtain the session key.
To guarantee a correct IPoE session configuration and a correct authentication database, the migration is performed when the host state is renewed, and a new trigger packet is received:
DHCPv4 renew or rebind for DHCPv4 hosts
DHCPv6 renew or rebind for DHCPv6 hosts (IA-NA and IA-PD)
DHCPv4 renew for IPoE linked SLAAC hosts
Router Solicit for RS triggered SLAAC hosts
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.
The following notes must be considered for the migration procedure:
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.
Example high-level migration steps.
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.
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.
Check if all preconditions are met:
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.
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.
Authentication servers are up to date to provide all required authentication data for a single dual-stack end device based on single authentication (for example, return both IP address and IPv6 prefix in a proxy scenario).
Accounting servers are ready to deal with accounting stop/start when hosts migrate to an IPoE session.
Take a snapshot of the active hosts before the migration. Use the commands as described above. The following command provides a summary view: tools>dump>router <router-instance>ipoe-session>migration>interface <group-int-name>
Start the migration by enabling an IPoE session on the group interface and for MSAPs, by enabling an IPoE session on the capture SAP.
Monitor the progress during migration. Review the events (for example, by using the show log log-id 99 command) and check the number of hosts migrated with the CLI command:
tools>dump>router <router-instance>ipoe-session>migration>interface <group-int-name>
The following event is generated when a host is deleted because of a migration:
4 2015/06/29 19:37:57.47 UTC WARNING: SVCMGR #2559 Base IPoE session "IPoE session migration deleted host 2001:db8:2:101::1 on SAP 1/1/4:1201.2 in service 1000"
2 2015/06/29 19:37:29.41 UTC WARNING: SVCMGR #2559 Base IPoE session "IPoE session migration deleted host 10.1.1.101 on SAP 1/1/4:1201.2 in service 1000"
DHCP lease states and SLAAC host states associated with IPoE sessions can be found with:
show service id <service-id> dhcp4 lease-state interface <group-int-name> session ipoe
show service id <service-id> dhcp6 lease-state interface <group-int-name> session ipoe
show service id <service-id> slaac host interface <group-int-name> session ipoe
The migration is finished when all hosts are associated with an IPoE session. The counters in the column ‟Non IPoE session” should be all zero. For example:
# tools dump router ipoe-session migration interface group-int-1-1
============================================================================
Type session Total IPoE session Non IPoE
============================================================================
Group-interface: group-int-1-1 (IPoE session enabled)
----------------------------------------------------------------------------
DHCPv4 16384 16384 0
DHCPv6 16384 16384 0
SLAAC 4096 4096 0
----------------------------------------------------------------------
IPoE sessions 20480
=========================================================================
Perform post migration steps. For example, verify that the number of users before and after the migration are in the same order of magnitude (users may connect and disconnect during the migration). Enable session accounting if required.