The Layer-3 redundancy feature will support Active-Standby Model. The Layer-3 redundancy role is driven by user configuration at both the primary and secondary Mobility Master. Once the systems are set up for Layer-3 redundancy, the switchover event will take place when the primary Mobility Master goes down. The secondary Mobility Master will provide the Mobility Master functionality without any user intervention. Layer-3 redundancy determines if the user can make configuration changes and if the sync will be initiated.

Managed devices will have the management tunnel with only one Mobility Master at any given time. The managed device will try to connect to the secondary Mobility Master if it looses connectivity with the primary Mobility Master. The secondary Mobility Master will accept the management tunnel connections from a managed device only if its tunnel with primary Mobility Master is down. This will ensure that the Layer-3 switchover event is processed only if the primary Mobility Master is down and not due to flaky connectivity between the managed device and primary Mobility Master.

Listed below are the salient features of Layer-3 Redundancy:

Configuration and database events are synced automatically from the primary to secondary Mobility Master.

Managed devices detect a failure in the primaryMobility Master and automatically switch to the secondary Mobility Master.

The switchover event in the managed device will have minimal service impact if any.

Centralized licensing, a single license for both primary and secondary Mobility Masters.

Layer-2 and Layer-3 redundancy will work together.

When the primary Mobility Master comes back up all managed devices will switch back to primary Mobility Master with minimal service impact, if any.

In the WebUI:

1. In the Mobility Master node hierarchy, navigate to the Configuration > Redundancy > L3 redundancy tab.

2. Select the Conrtoller role.

3. Enter the Sync period (in hours). The minimum value is 2 hours and the maximum value is 24 hours.

4. Enter the IP address of the peer.

5. Select the authentication method from the Authentication drop-box.

a. If IPSec key is selected as an authentication method, enter the IPSec key of the peer and Re-type the key

b. If Certificate is selected as an authentication method and Factory is selected as the Certificate type, enter thePeer's MAC address

c. If Certificate is selected as an authentication method and Custom is selected as the certificate type, enter the Peer's MAC address, CA certificate, Server Certificate and select a Suite B algorithm from the drop-down list.

6. Click Submit.

7. Click Pending Changes.

8. In the Pending Changes window, select the check box and click Deploy changes.

Configuration changes cannot be made on the secondary Mobility Master. In a scenario where the primary Mobility Master is down and configuration changes need to be made on the secondary Mobility Master the user must change the sync state of the secondary Mobility Master to primary.

To preserve these configuration changes, a Layer-3 synchronization between the new primary Mobility Master and the old primary Mobility Master should take place. For the synchronization to take place the sync state of the old primary Mobility Master should be changed from primary to secondary state.

When the L3 sync state of a Mobility Master is changed from primary to secondary, the Mobility Master reboots to ensure a proper cleanup of the Mobility Master before new configurations or data is pushed from the new primary Mobility Master.

Once the roles of Mobility Masters are reversed, the user should ensure the managed devices point to the correct primary Mobility Master and secondary Mobility Master by changing the respective master IP address addresses.

The change of master IP and secondary master IP address that takes place on the primary Mobility Master from the managed device node should be done in the same write memory cycle. If this procedure is not done in same write memory cycle, the managed devices may point to the same IP as their primary and secondary Mobility Masters. If this happens reconfiguring the correct secondary masterip when the managed devices are up will fix the issue.

The change of master IP and secondary master IP address that takes place on the primary Mobility Master from the managed device node should be done in the same write memory cycle. If this procedure is not done in same write memory cycle, the managed devices may point to the same IP as their primary and secondary Mobility Masters. If this happens reconfiguring the correct secondary masterip when the managed devices are up will fix the issue.

Data synchronization between the Layer-3 peers only happens for the data that is already synced between Layer-2 pairs.

Table 1: Layer-3 Synchronization

	Synchronized Across Layer-3 Peers
Configuration	Yes
Database	Yes
Certificates	Yes
Captive PortalA captive portal is a web page that allows the users to authenticate and sign in before connecting to a public-access network. Captive portals are typically used by business centers, airports, hotel lobbies, coffee shops, and other venues that offer free Wi-Fi hotspots for the guest users.	Yes
Dynamic State Information of Services	No
Monitoring Data	No
Data Distribution Service State	No

The Activate provisioning rule is enhanced to include the following data when Layer-3 Redundancy level is configured. Separate titles for primary data center and secondary data center are displayed to differentiate information.

Primary Data Center Secondary Data Center

=================== =====================

Primary Master Controller: Primary Master Controller:

Master Controller IP: Master Controller IP:

Secondary Master Controller: Secondary Master Controller:

Primary VPN Concentrator MAC: Primary VPN Concentrator MAC:

VPN Concentrator IP: VPN Concentrator IP:

Secondary VPN Concentrator MAC: Secondary VPN Concentrator MAC:

The Health Check Manager provides detailed information on the health of uplinks. The Health Check Manager periodically pings and reports if the devices at the other end of the uplinks are reachable. Each managed device interfaces with the Health Check Manager that provides information on the state of uplinks in both the primary and the secondary Mobility Master.

The secondary Mobility Master allows the connection only if it determines that the primary Mobility Master is also down.

The Load Balancing feature, provides a way to load balance across multiple uplinks between the same end points or across Mobility Masters.

Support is provided only for one active management tunnel. There is no support for load balancing the management traffic.