India’s largest bank trusted us for the most complicated hardware migration.
The client is a well-respected private sector bank in India. Offering a wide range of banking products and services for corporations and retail customers, the bank provides guidance for personal finances, investment banking, life insurance, and wealth management. The bank has a network of 1,369 branches in 689 locations and more than 2000 ATMs across India, making it one of the largest private banks in the country.
Managing Changes and Migration of the Core and Perimeter Layers
The core and perimeter layers of the system in one of their data centers were experiencing performance issues and needed to be migrated to a new system over a single weekend. Their disaster recovery branch had Fortigate installed as the core layer and Check Point as the perimeter layer. The bank wanted to have a single high-end Check Point installed to manage core and Internet traffic. To accomplish this, a routing modification was required to merge the Fortigate database to Check Point along the same changes made to the NAT configuration.
The rack space did not have any additional allotment for new devices, so it would be necessary to remove the existing devices before installing the new ones.
The core layer in DC had more than 45 interfaces, 20 of which were physical and 25 were logical. During the change, the client wanted to reduce the number of physical interfaces to six, then use sub-interfaces or logical interfaces for the other 14 interfaces. They wanted this completed within a ten-minute time frame. The perimeter layer had the same challenges, but there were fewer than ten interfaces to manage.
The core layer in DR required the migration of the Fortigate object and policy database to Check Point without the Check Point tool is available. The perimeter layer faced the same challenges, with the addition of more interfaces to manage from Fortigate and network re-routing.
Solution – Coordinated Changes
The solution for both the DC and DR core and perimeter layers was the same, although they had to be completed separately. QOS used a dedicated management network between the management server and gateways so that the network would not have data traffic. The network was solely used for logs and policy installation. By setting up a cluster before initiating the downtime, the team unplugged the cables first from the existing standby device. They then removed the device from the rack and mounted the new device in place. This allowed the traffic to continue to pass through the active server during the change. When the system was down, they unplugged the cables from the current device and plugged them into the newly installed one.
They also monitored the traffic during the entire process. Some DHCP relay issues surfaced but were quickly resolved so that there were no performance issues once the new device was active.
To migrate the Fortigate database to the Check Point, QOS used the third party AlgoSec automation tool. Coordinating with the customer, we analyzed changes in the network architecture and modified the static routes based on those analyses. As a result, all traffic was diverted to the new Check Point device.
A Successful Migration with Minimal Downtime
Given the sensitive and essential nature of the tasks, the team was limited to no greater than 10 minutes of downtime, which proved to be more time than the QOS team needed. The customer environment experienced less than a minute of downtime at all four locations. Minor issues encountered following the migration were resolved during regular maintenance windows. As a result, the client was very satisfied with the end result of our solution.