Home Agent Redundancy

This chapter discusses several concepts related to Home Agent redundancy, how Home Agent redundancy works, and how to configure redundancy on the Cisco Mobile Wireless Home Agent.

This chapter includes the following sections:

•Overview of Home Agent Redundancy

•Geographical Redundancy

•Redundancy with Radius Downloaded Pool Names

•HSRP Groups

•How HA Redundancy Works

•Physical Network Support

•Virtual Networks

•Support for Discontinuous IP Address Pools for the Same Realm

•Configuring HA Redundancy

•Home Agent Redundancy Configuration Examples

Overview of Home Agent Redundancy

Cisco Home Agents can be configured to provide 1:1 redundancy. Two Home Agents are configured in hot-standby mode, based on Cisco Hot Standby Routing Protocol (HSRP in RFC 2281). This enables the active Home Agent to continually copy mobile session-related information to the standby Home Agent, and maintains synchronized state information at both Home Agents. In case an active Home Agent fails, the standby Home Agent takes over without service disruption.

Note NAI support in the Mobile IP HA redundancy feature provides capabilities specific to CDMA2000 for Home Agent redundancy. The CDMA2000 framework requires address assignment based on NAI, and support of multiple static IP addresses per user NAI.

The Home Agent redundancy feature is supported for Static IP Address assignment and IP Address assignment by AAA. Starting in Release 2.0, the Home Agent redundancy feature is supported for Dynamic IP Address assignment using local IP address pools and Dynamic IP Address assignment using Proxy DHCP.

When Home Agent redundancy is configured with Dynamic IP Address assignment using Proxy DHCP, the DHCP information is not synced with the standby while the bindings are brought up, even though the bindings are synced to the standby HA. However, when the standby HA becomes active, a DHCP request for each existing binding is sent out to the DHCP server in order to update the DHCP related information on this Home Agent.

The following features are not supported with HA redundancy:

•Hot-lining support on the HA.

•ODAP/DHCP and local pool addressing schemes are not supported with peer-peer redundancy.

During the Mobile IP registration process, an HA creates a mobility binding table that maps the home IP address of an MN to the current care-of address of the MN. If the HA fails, the mobility binding table is lost and all MNs registered with the HA lose connectivity. To reduce the impact of an HA failure, Cisco IOS software supports the HA redundancy feature.

Note On configurations based on the Cisco 7600 series platform, the backup Home Agent image is configured on a different SAMI card from the primary.

The functionality of HA redundancy runs on top of the Hot Standby Router Protocol (HSRP). HSRP is a protocol developed by Cisco that provides network redundancy in a way that ensures that user traffic immediately and transparently recovers from failures.

Note HA Session Redundancy is not supported on the Cisco 7301 Series Router.

Geographical Redundancy

Home Agents in a redundant pair can be placed at geographically separate locations using a VPN solution (such as one based on MPLS) instead of a LAN/VLAN between Home Agent pairs. Such a deployment needs to implement correct routing logic in the network to route traffic to one of the Home Agents in the pair. If there is a network failure, both the HAs could transition to HSRP active state in such a deployment. The Home Agent Redundancy feature recovers from such a failure gracefully with minimal loss of bindings. The following scenario describes the failure recovery process:

1. HA1 (high priority) and HA2 (low priority) are deployed in redundant mode over a WAN link. HSRP is running between the home agents over the WAN link.

2. HA1 is active and HA2 is standby.

3. WAN connectivity to HA1 is lost, due to a network fault, so the HSRP link between HA1 and HA2 is lost.

4. HA2 does not receive hello packets, and transitions to active. HA1 remains active as well, for the same reason (the box itself is functional). If this feature is enabled, both HA1 and HA2 lower their priority.

5. Mobile traffic and signaling messages are routed to HA2. HA2 updates its binding table accordingly and if the feature is enabled, increases its priority back to the original value. But the changed home agent state information on HA2 do not get synched to HA1 (which is unreachable).

6. Network fault is corrected, and hello packets exchanged between HA1 and HA2.

7. Without this feature, HA1 remains active and HA2 moves to become standby, leading to loss of latest state information as created on HA2 at step #5. If this feature is enabled, HA1 moves to become standby and HA2 remains active. Hence latest information on HA2 gets synched to HA1. Once state information is replicated, HA1 moves back to its normal priority. This leads to HA1 becoming active and HA2 becoming standby.

As described above, the latest state information is maintained after network fault is corrected. To enable this feature, following commands should be configured on the HA:

track tracking object id application home-agent

This command creates a tracking object to track the home-agent state.

standby track tracking object id decrement priority

This command enables lowering priority as required by step #4 in the above failure scenario.

Note If preemption is configured, the priority value should be greater than the difference in priorities of the active and standby Homeagents.

Redundancy with Radius Downloaded Pool Names

The Cisco Mobile Wireless HA supports AAA downloadable pool names for address allocation. The radius pool-name attributes returned in an access accept for address allocation are "ip-pool" for dynamic address allocation, and "static-ip-pool" for static address authorization. The pool name returned in an access accept to the Home Agent will be synched to standby Home Agent during normal and bulk sync operation. This enables address allocation from the same pool on the standby Home Agent as well.

HSRP Groups

Before configuring HA Redundancy, you must understand the concept of HSRP groups.

An HSRP group is composed of two or more routers that share an IP address and a MAC (Layer 2) address and act as a single virtual router. For example, your Mobile IP topology can include one active HA and one or more standby HAs that the rest of the topology view as a single virtual HA.

You must define certain HSRP group attributes on the interfaces of the HAs so that Mobile IP can implement the redundancy. You can use the groups to provide redundancy for MNs with a home link on either the interface of the group (a physical network) or on virtual networks. Virtual networks are logical circuits that are programmed and share a common physical infrastructure.

How HA Redundancy Works

The HA Redundancy feature enables you to configure an active HA and one or more standby HAs. The HAs in a redundancy group may be configured in an active HA-standby HA role if the HAs are supporting physical networks, or in a Peer HA-Peer HA role if they are supporting virtual networks.

In the first case, the active HA assumes the lead HA role, and synchronizes the standby HA. In the case of virtual network support, Peer HAs share the lead HA role and "update" each other. The Peer HA configuration allows for load balancing of the incoming RRQs, as either HA may receive RRQs. In either scenario, the HAs participating in the redundancy group should be configured similarly. The current support structure is 1 to1 to provide the maximum robustness and transparency in failover.

HA functionality is a service provided by the router and is not interface specific. Therefore, the HA and the MN must agree on which HA interface the MN should send its registration requests and, conversely, on which HA interface the HA should receive the registration requests. This agreement must factor in the following two scenarios:

•An MN that has an HA interface (HA IP address) that is not on the same subnet as the MN.

•An MN that requires the HA interface to be on the same subnet as the MN; that is, the HA and the MN must be on the same home network.

For MNs on physical networks, an active HA accepts registration requests from the MN and sends binding updates to the standby HA. This process keeps the mobility binding tables on the active and standby HAs synchronized.

For MNs on virtual networks, the active and standby HAs are peers—either HA can handle registration requests from the MN and update the mobility binding table on the peer HA.

When a standby HA comes up, it must request all mobility binding information from the active HA. The active HA responds by downloading the mobility binding table to the standby HA. The standby HA acknowledges that it has received the requested binding information. Figure 1 illustrates an active HA downloading the mobility bindings to a standby HA. A main concern in this stage of the process is which HA IP interface the standby HA should use to retrieve the appropriate mobility binding table, and on which interface of the standby HA the binding request should be sent.

Figure 1 Overview of HA Redundancy and Mobility Binding Process

Note The active HA-standby HA can also be in peer HA-peer HA configuration.

Physical Network Support

For MNs on physical networks, the HAs are configured in the active HA-standby HA configurations as shown in Figure 2 and Figure 3. The MNs that are supported on this physical network are configured with the HSRP virtual group address as the HA address. Hence, only the active HA can accept RRQs from the MN because it is the owner of the HSRP virtual group address. Upon receipt of an authenticated RRQ, the active HA sends a binding update to the standby HA.

HA Redundancy for physical networks can support multiple HAs in the redundancy group, although only one HA can be in active state, and only one HA can be in standby state. For example, consider the scenario in which there are four HAs in the redundancy group (that is, one active HA, one standby HA, and two HAs in listen state). If the active HA fails, the standby HA becomes the active HA, and the HA in listen state with higher priority becomes the standby HA.

Figure 2 Virtual Network Support Using One Physical Network (Peer HA-Peer HA)

Figure 3 Virtual Network Support Using Multiple Physical Networks (Peer HA-Peer HA)

Virtual Networks

Mobile IP calls for each MN are associated with the home network from which the MN's home IP address is allocated. It is often assumed that this should be a physical network, but there are many cases in deployment where it does not make sense to have each MN attached to a physical network. IOS Mobile IP supports the creation of a software interface called a virtual network. A virtual network is very similar to a loopback interface, but it is owned by the Mobile IP process. Using virtual networks saves Interface Descriptor Blocks (IDBs), and allows Mobile IP specific control over how packets are dropped. When using virtual networks the mobile node is always considered roaming, it can never be attached to its home network. In real world deployments, this can cause some semantic problems. For example in cellular deployment a user may be in their home calling area, but will be roaming from a Mobile IP perspective.

Virtual networks are configured and referenced by a network number and mask pair. It is also possible to associate the virtual network with a Home Agent address for redundancy purposes. Here is an example: 

ip mobile virtual-network 10.0.0.0 255.255.255.0 address 192.168.100.1

ip mobile host 10.0.0.1 10.0.0.254 virtual-network 10.0.0.0 255.255.255.0

Virtual network routes are owned by the Mobile IP routing process and therefore must be redistributed into other routing protocols in order to be propagated. Here is an example: 

router rip

  redistribute mobile

Support for Discontinuous IP Address Pools for the Same Realm

This feature allows the user to specify discontinuous IP address pools for the same realm so that mobiles with NAI can have home addresses assigned from a pool of discontiguous IP address ranges. This will allow the Home Agent to accept Mobiles belonging to multiple virtual networks for the same host group.

This is achieved by configuring a local pool on HA covering the IP address ranges for multiple virtual-networks, and specifying one of the virtual-networks as the home network for the given realm.

The following configuration can be used to allow the HA to accept MNs belonging to multiple virtual networks for the same host group. 

ip local pool pool1 10.1.1.1 1.1.1.250

ip local pool pool1 10.1.2.1 1.1.2.250


ip mobile home-agent

ip mobile virtual-network 10.1.1.0 255.255.255.0

ip mobile virtual-network 10.1.2.0 255.255.255.0

ip mobile host nai @xyz.com address pool local pool1 virtual-network 10.1.1.0 
255.255.255.0 aaa lifetime 65535

In the above configuration, two virtual networks are configured and the local pool (pool1) is configured to include the IP addresses for both the virtual networks. By specifying one of the virtual networks and the local pool name in the ip mobile host command, the HA will accept MNs belonging to both the networks for the same realm.

Priority Metric for Local Pool

In order to support the ability to change addressing schemes dynamically, a priority metric on a local address pool is introduced. This allows you to create a high priority address pool with the new address scheme. New bindings utilize this new address pool. Existing subscribers continue to use their current address until they disconnect, and upon reconnect they are allocated an address from the new pool. When all subscribers age out of the old address pool, it can be removed.

Currently, different addressing schemes (range of addresses) are configured under the same pool name, and the IP address will be assigned from the pool in the order of configuration. Initially, the first configured range of addresses is used to assign the IP Address, and when all the addresses have been utilized, the subsequent range is then used to assign IP Address, and so on.

To override the above default behavior and configure subscribers to have different address scheme, a priority value is introduced with the pool. This allows you to use the higher priority pool over the lower priority one so that when a new registration request comes, the IP address is assigned from the desired pool.

By default, a priority value of 255 (high priority) is assigned to a newly created local pool. The pool priority value takes a value of 1 to 255, where 0 is less, and 255 is the higher priority.

Here is an example: 

ip local pool hapool 1.0.0.0 1.0.0.255 

ip local pool hapool 2.0.0.0 2.0.0.255

This example creates local pools with the priority of 255. An IP address is assigned in the order of configuration if more than one address scheme has the same priority. Initially, all 255 hosts are assigned from the first pool, and the second one will be used for subsequent requests. 

ip local pool hapool 1.0.0.0 1.0.0.255 priority 200

ip local pool hapool 2.0.0.0 2.0.0.255 priority 100

This example creates local pools with the priority of 255. In this case, the IP address is assigned in the order of priority. Initially all 255 hosts are assigned from the second pool (which has a higher priority 100), and the first pool (priority 200) is used for subsequent requests.

Configuring Local Pool Priority Values

To configure a priority value for a local pool, perform the following task:

 
Command
Purpose

Step 1 

Router(config)#ip local pool {default | poolname} [low-ip-address [high-ip-address]] [group group-name] [cache-size size] [priority 1-255] [theshold low-threshold high-threshold]

Configures a local pool of IP addresses to be used when a remote peer connects to a point-to-point interface, to generate traps when pool utilization reaches a high or low threshold in percentage.

The new option priority 1-255 is allows you to assign a priority to a newly created pool, and this priority is used to assign IP addresses.

Configuring HA Redundancy

Home Agent Redundancy Tasks (Required for Mobile IP)

To configure your routers for Mobile IP HA redundancy, perform the required tasks described in the following sections:

•Enabling Mobile IP (Required)

•Enabling HSRP (Required)

•Configuring HSRP Group Attributes

•Enabling HA Redundancy for a Physical Network (Required)

•Configuring Geographical Redundancy

•Enabling HA Redundancy for a Virtual Network Using One Physical Network

•Configuring HA Load Balancing

Enabling Mobile IP

To enable Mobile IP on the router, use the following command in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)#router mobile

Enables Mobile IP on the router.

Enabling HSRP

To enable HSRP on an interface, use the following command in interface configuration mode:

 
Command
Purpose

Step 1 

Router(config-if)#standby [group-number] ip ip-address


Enables HSRP.

Configuring HSRP Group Attributes

To configure HSRP group attributes that affect how the local router participates in HSRP, use either of the following commands in interface configuration mode:

 
Command
Purpose

Step 1 

Router(config-if)#standby [group-number] priority

priority [preempt [delay [minimum | sync] delay]]

or


Router(config-if)#standby [group-number] [priority

priority] preempt [delay [minimum | sync]

delay]

Sets the Hot Standby priority used in choosing the active router. By default, the router that comes up later becomes standby. When one router is designated as an active HA, the priority is set highest in the HSRP group and the preemption is set. Configure the preempt delay min command so that all bindings will be downloaded to the router before it takes the active role. The router becomes active when all bindings are downloaded, or when the timer expires, whichever comes first.

Step 2 

Router(config-if)# standby group-number follow group-name


Specifies the number of the follow group and the name of the primary group to follow and share status.

We recommend that the specified group number is the same as the primary group number.

Enabling HA Redundancy for a Physical Network

To enable HA redundancy for a physical network, use following commands beginning in interface configuration mode:

 
Command
Purpose

Step 1 

Router(config-if)#standby [group-number] ip ip-address

Enables HSRP.

Step 2 

Router(config-if)# standby name hsrp-group-name

Sets the name of the standby group.

Step 3 

Router(config)#ip mobile home-agent redundancy hsrp-group-name

Configures the Home Agent for redundancy using the HSRP group name.

Step 4 

Router(config)#ip mobile secure home-agent address spi spi key hex string

Sets up the Home Agent security association between peer routers. If configured on the active HA, the IP address argument is that of the standby HA. If configured on the standby HA, the IP address address argument is that of the active router. Note that a security association needs to be set up between all HAs in the standby group.

Configuring Geographical Redundancy

To enable Geographical redundancy on the Home Agent, perform the following tasks:

 
Command
Purpose

Step 1 

Router(config)# track tracking object id application home-agent

Creates a tracking object to track the home-agent state.

Step 2 

Router(config)# standby track tracking object id decrement priority

Enables HAs to lower their priority as required in a failure scenario.

Enabling HA Redundancy for a Virtual Network Using One Physical Network

To enable HA redundancy for a virtual network and a physical network, use the following commands beginning in interface configuration mode:

 
Command
Purpose

Step 1 

Router (config-if)# standby [group-number] ip ip-address

Enables HSRP.

Step 2 

Router(config)#ip mobile home-agent address address


or





Router(config)#ip mobile home-agent

Defines a global Home Agent address. In this configuration, the address is the HSRP group address. Enter this command if the mobile node and Home Agent are on different subnets.

or

Enables and controls Home Agent services to the router. Enter this command if the mobile node and Home Agent are on the same subnet.

Step 3 

Router(config)#ip mobile virtual-network net mask [address address]

Defines the virtual network. If the mobile node and Home Agent are on the same subnet, use the [address address] option.

Step 4 

Router(config)# ip mobile home-agent redundancy hsrp-group-name [[virtual-network] address address]

Configures the Home Agent for redundancy using the HSRP group to support virtual networks.

Step 5 

Router(config)# ip mobile secure home-agent address spi spi key hex string

Sets up the Home Agent security association between peer routers. If configured on the active HA, the IP address address argument is that of the standby HA. If configured on the standby HA, the IP address address argument is that of the active router. Note that a security association needs to be set up between all HAs in the standby group.

Configuring HA Load Balancing

To enable the HA Load Balancing feature, perform these tasks:

 
Command
Purpose

Step 1 

Router(config)# ip mobile home-agent dynamic-address ip address

Sets the Home Agent Address field in the Registration Response packet. The Home Agent Address field will be set to ip address.

Home Agent Redundancy Configuration Examples

Active-HA configuration 


version 12.2

no service pad

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname mwt10-7206b

!

aaa new-model

!

aaa authentication ppp default local group radius

aaa authorization config-commands

aaa authorization ipmobile default group radius

aaa authorization network default group radius

aaa session-id common

!

ip subnet-zero

ip cef

!

interface Ethernet2/0

 description to PDSN/FA

 ip address 10.0.0.2 255.0.0.0

 no ip route-cache

 no ip mroute-cache

 duplex half

 standby ip 10.0.0.4

 standby priority 110

 standby preempt delay min 100

 standby name cisco

!

interface Ethernet2/2

 description to AAA

 ip address 172.16.1.8 255.255.0.0

 no ip route-cache

 no ip mroute-cache

 duplex half

!

router mobile

!

ip local pool ha-pool 10.0.0.1 10.0.0.254

ip classless

no ip http server

ip pim bidir-enable

ip mobile home-agent

ip mobile home-agent redundancy cisco

ip mobile host nai mwts-mip-np-user1@ispxyz.com static-address 40.0.0.1 interface 
Ethernet2/0 aaa

ip mobile secure home-agent 7.0.0.3 spi 100 key ascii redundancy algorithm md5 mode 
prefix-suffix

!

radius-server host 172.16.0.2 auth-port 1645 acct-port 1646

radius-server retransmit 3

radius-server key cisco

call rsvp-sync

!

mgcp profile default

!

dial-peer cor custom

!

gatekeeper

 shutdown

!

line con 0

line aux 0

line vty 0 4

!

end

Standby-HA configuration 

~~~~~~~~~~~~~~~~~~~~

version 12.2

no service pad

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname mwt10-7206b

!

aaa new-model

!

aaa authentication ppp default local group radius

aaa authorization config-commands

aaa authorization ipmobile default group radius

aaa authorization network default group radius

aaa session-id common

!

ip subnet-zero

ip cef

!

interface Ethernet2/0

 description to PDSN/FA

 ip address 10.0.0.3 255.0.0.0

 no ip route-cache

 no ip mroute-cache

 duplex half

 standby ip 10.0.0.4

 standby name cisco

!

interface Ethernet2/2

 description to AAA

 ip address 172.16.1.7 255.255.0.0

 no ip route-cache

 no ip mroute-cache

 duplex half

!

router mobile

!

ip local pool ha-pool 10.0.0.1 10.0.0.255

ip classless

no ip http server

ip pim bidir-enable

ip mobile home-agent

ip mobile home-agent redundancy cisco

ip mobile host nai mwts-mip-np-user1@ispxyz.com static-address 40.0.0.1 interface 
Ethernet2/0 aaa

ip mobile secure home-agent 10.0.0.2 spi 100 key ascii redundancy algorithm md5 mode 
prefix-suffix

!

radius-server host 172.16.0.2 auth-port 1645 acct-port 1646

radius-server retransmit 3

radius-server key cisco

call rsvp-sync

!

mgcp profile default

!

dial-peer cor custom

!

gatekeeper

 shutdown

!

line con 0

line aux 0

line vty 0 4

!

end

Redundancy Support for Hotlining

In HA release 4.0 and above, redundancy is supported for both Rule-based and Profile-based hot-lining. In profile-based hotlining, the active-HA will only sync only the profile's information to standby; it will not sync rules that are available under the profile.

Note HA3.1 does not support HSRP-HA redundancy for the hot-lining feature.

In rule-based hot-lining, after receiving and validating the COA message content, the active HA will sync part of the COA related information to the standby, and even interim syncs happen at the standby whenever rules are updated with the COA content by the AAA server. The following information will be synched to standby:

•User-Name: the mandatory attribute while syncing rules to the standby HA.

•MN Address: provided if the MN session (binding) has already been established.

•Hot-Line Accounting Indication: this field is used when the failover happens to send in accounting messages.

•Filter-Id: specifies the hot-lining status for a particular user. An active HA receives no more than one filter-id per user, and should sync to the standby HA. Each filter-id contains pre-provisioned hot-line profiles for the corresponding profile-id (filter-id).

•Filter-Rules: contains the IP and HTTP filter rules, there is possibility of more than one filter rule.

•IP-Redirection-Rules: contains IP redirection rules. There is the possibility of zero or more IP redirection rules.

•HTTP-Redirection-Rules: contains HTTP redirection rules. There is the possibility of zero or more HTTP redirection rules.

•Accounting-Session-Id: provided if the session is created and user is hot-lined. When a user is hot-lined a new "accounting session id" is created.

•Session-Timeout: indicates the maximum number of seconds of service provided to the user before termination of the session or prompt.

If the failover happens and the standby becomes active, it will apply the syncing rules on the user. If the session is established and matching is done, the user will be hot-lined. If the session is not established, it will wait until session establishment for a particular user.

In redundancy / failover, the new active HA uses the same Accounting-Session-Id that was synced before failover.

Redundancy Support for QoS

HA release 4.0 and above does not support flow-based QoS policing involving continuous updates of dynamic runtime policymap information between active and standby HA. Since the HA only supports normal and bulk sync, any periodic updates of policing data or counter statistics will not be accurate.

Redundancy Support for Call admission Control (CAC)

At present there is no requirement to support redundancy for Call admission control (CAC). However, the backup Home Agent maintains its own state.

Redundancy Support for MIP/LAC

Redundancy is not supported for the MIP-LAC feature as part of Release 4. However, care will be taken to make failover as graceful as possible.

Redundancy Support for Framed-pool Standard

Redundancy is supported with this feature. No additional commands need to be enabled to support this feature.

Redundancy Support for Priority-metric for Local Pool

Redundancy is supported with this feature. No additional commands need to be enabled to support this feature.

Redundancy Support for Mobile IPv4 Host Configuration Extensions

Redundancy is supported with this feature. No additional commands need to be enabled to support this feature.

Redundancy Support for WiMAX AAA Attributes

Redundancy is supported with this feature. No additional commands need to be enabled to support this feature.

When HA redundancy is enabled, all attributes included in Access-Request and Accounting messages from the active are also present in the corresponding messages from the standby after switchover. Additionally, interim accounting messages are sent from the standby in the same interval as they are sent from the active. In order to achieve this, the values of the following attributes are synced to the standby.

•Chargeable User Identity (89)

•Acct-Multi-Session-Id (50)

•Acct-Interim-Interval (85)

Redundancy Support for SAMI Migration

It is necessary to have redundancy set up for seamless migration, and to prevent disruption in service. Please refer to the User Migration section in Planning to Configure the Home Agent chapter for details on how to migrate to the SAMI plarform.