Cisco Cisco IOS Software Release 12.4(15)XM
7
Release Notes for the Cisco Mobile Wireless Home Agent Feature in Cisco IOS Release 12.4(15)XM
System Requirements
offers various steps you need to take in order to migrate to the SAMI platform. Each of the
possible migration scenarios is considered.
Table 4
Migration Steps that Correspond to Migration Scenarios from
Scenario
Migration Steps
1
•
Install and configure the Home Agent on the Cisco 7600/SUP720 with SAMI.
•
Provision MS and Foreign Agents to use the newly added SAMI-based Home Agent (this may be a very large
task).
task).
•
Instead of large provisioning tasks, the SAMI Home Agent can reuse the 7200 NPE-G1-based Home Agent
IP addresses and routing schemes (presuming that this is done in a maintainence window, and service is
disrupted).
IP addresses and routing schemes (presuming that this is done in a maintainence window, and service is
disrupted).
2
•
Install and configure the Home Agent on a Cisco 7600/SUP720 with SAMI and SLB enabled. The Home
Agent SLB needs to be tested on SUP720 SRC release.
Agent SLB needs to be tested on SUP720 SRC release.
•
Provision the MS and foreign agents to use the newly added SAMI-based Home Agents (this may be a very
large provisioning task).
large provisioning task).
3
•
Install and configure the Home Agent on a Cisco 7600/SUP720 with SAMI, and put them in the same HSRP
redundancy group as configured on a 7200-based HA.
redundancy group as configured on a 7200-based HA.
•
Configure higher priority and HSRP preemption on the SAMI-based HA.
Note
SAMI HA R4.0 may not be backward compatible in term of redundancy
–
HA R4.0 has per-binding based features such as rule-based hotlining, and QoS and host extension
attributes (the per-binding feature is also applicable for profile-based hotlining). This actually increases
per-binding information compared to the per-binding information in R3.1, or prior. Synching bindings
from R4.0 to 3.0 and prior works. So far the binding information is only information synched between
the active HA and standby HA in HA R3.x.
attributes (the per-binding feature is also applicable for profile-based hotlining). This actually increases
per-binding information compared to the per-binding information in R3.1, or prior. Synching bindings
from R4.0 to 3.0 and prior works. So far the binding information is only information synched between
the active HA and standby HA in HA R3.x.
–
If HA R4.0 high availability is L3-based, rather than L2 HSRP based, stateful redundancy from HA R3.x
to HA R4.0 will not be compatible. If this is the case, the configuration for this redundancy will be quite
different between the two releases.
to HA R4.0 will not be compatible. If this is the case, the configuration for this redundancy will be quite
different between the two releases.
–
HA R4.0 does batch mode for bulk-sync while HA R3.x sync is on a per binding basis.
•
This is the ideal case, and does not have to be done in a maintainence window.
4
•
For the single chassis, changing from SUP2 to SUP720 is a non-trivial task. The whole chassis is reset so all
service modules (such as MWAM and SAMI) are reset, too.
service modules (such as MWAM and SAMI) are reset, too.
•
You have to perform this migration during a maintanence window, and user service will be disrupted.
•
You must verify HA-SLB.