Migrating from ClusterXL to ElasticXL steps

[DavidD]

Hello CheckMates,

We are currently in a process of migrating x 2 5100 GW appliances in ClusterXL into x 2 QF 9100 GW appliances which will be running in ElasticXL mode.

Since there is no official procedure or steps to do this migration, i would appreciate any advisory help regarding the steps needed to be taken to be successful.

It would be great if we were moving to completely new infrastructure, but customer wants to keep exact interface and gateway setups as it is currently.

1. Upgrade current management server to R82
2. Add ElasticXL pivot gateway
3. Clone current access policy & adapt it to ElasticXL

4. Creating interfaces on ElasticXL

4a I am unsure on this part if i can use the same exact ip address for gateway or do i need to use different ones, eg 192.168.1.1 and 192.168.1.9 for the same VLAN.

5. Mirror copy the same configuration of cluster ( IPSEC tunnels, logging, other etc..)
6. Unplug old gateways.
7. Physically connect external connections to ElasticXL devices

8. Install policy

First two steps are obviously done, but i am unsure on what is the best course of action for this, i am concerned about the interface gateways, and to not get cut off from management server, since they do not have an out of bounds management vlan network, but it is on one of the production networks.

Also original plan was to use a different new management server which we booted and configured, but we fell back to the old one because the user must be able to migrate IPSEC tunnels without having to reconfigure anything again.

What would your advice be to make this as smooth as possible?

Any help would be appreciative 😊

[Bob_Zimmerman]

3. I wouldn't clone the policy. I would just install the same policy to both. Find anywhere the old cluster object is used and add the new ElasticXL object.

4. You use the old cluster VIPs. Once you move to the ElasticXL cluster, the unique member IPs can be deallocated, though I would personally keep them in case I needed to move away from ElasticXL to a traditional cluster or even to another vendor. I really hate having my present options limited by old design decisions, so I try very hard not to do things which will limit future flexibility.

[DavidD]

4. How would you failover to ElasticXL cluster, i am a bit confused on how am i going to configure ElasticXL cluster IP's to be the exact same as ClusterXL VIP, won't i cut myself off? We will reserve the leftover ip addresses as you recommended.

For instance what if i do as follow:

ClusterXL VIP ip address 192.168.1.13 (.11 GW1 .12 GW2)
ElasticXL ip address 192.168.1.10

Fetch toplogy, add elasticXl object to policies, disconnect old gateways and install policy.

After that, ssh to pivot gateway and change the ip address to 192.168.1.13, fetch topology and install policy?

Would this be good workflow?

[Bob_Zimmerman]

That would probably be fine, though I would just treat it like moving from one vendor to another (from an ASA to Check Point, for example). I normally do that by using all the same IPs on the new boxes, and shutting down most of the switchports to them. For the cutover, shutdown the ports to the old boxes, 'no shutdown' the ports to the new boxes, push policy.

[DavidD]

This was my original plan as well with deploying a new management server, but sadly they need IPSEC tunnels migrated that are critical for which they do not have shared secrets anymore......as well as not having addition for ports on their switches for the new tunnel connection. Basically we will be reusing the same ports on the switch, just unplugging the old ClusterXL.

What will be tricky is that their management server is in their production VLAN, lets say 192.168.99.0/24.

MGMT IP is 192.168.99.20

Currently the management port of the new ElasticXL GW is in VLAN 192.168.1.0/24.

I need to change this port to vlan 192.168.99.X in order to not be cut off when i turn off the old ClusterXL GWs

Meanwhile i am unable to create these VIP addreses on the ElasticXL since they are used for management port.

After migrating to to ElasticXL i have to create a dummy ip address for management port and then recreate the VIP of VLAN 192.168.99.13

Any advice regarding this?

[Bob_Zimmerman]

As long as they're okay with a hard outage, it's easy enough. You can build the ElasticXL cluster object on the management with a different address (say, 192.168.99.14) and build the first ElasticXL member offline (all interfaces disconnected) with the real address. When it's time to cut over, unplug the old cluster members, plug in the first ElasticXL member, change the object's address to the real address, establish SIC, and push policy. This should get traffic working through the first ElasticXL member. There shouldn't be any more outages unless you roll back.

Once traffic is working through the first ElasticXL member, you can plug in the second member and add it to the ElasticXL cluster. There's no outage for that.

[DavidD]

They're ok with a hard outage, i feel pushed into a corner since on their previous implementation they did not use proper management ports, but used real sub interfaces for management.

Basically as i see it now, what i can do is:

1. Create the same .99 VLAN on first ElasticXL as sub interface, using a fake address 192.168.99.14
2. Fetch interface and topology, publish.
3. Have Console access to pivot GW
4. Disconnect trunk link to CLusterXL
5. Connect pivot GW by trunk to core sw
6. Change object's ip in SmartConsole to real ip address 192.168.99.13
7. Establish SIC and push policy.
8. Change the magg1 interface ip to dummy network, and recreate the same network as vlan.
9. Push policy.

I guess this would be the workflow then, if i forgot something feel free to add, i appreciate the help so far 🙂

[Bob_Zimmerman]

I try to avoid using the interface named Mgmt because people expect it to work like a management interface on an ASA or a Palo Alto. It doesn't. Unless you use VSX (or MDPS, which is related to VSX), the interface named Mgmt isn't special in any way. It's in the same routing table as all the other interfaces. Every environment I've seen which uses the interface named Mgmt and doesn't use VSX has asymmetric routing all over.

[the_rock]

Excellent point.

[_Val_]

Second that. No need to clone policy, and also new SMO with the old VIPs should be just fine as well.

[DavidD]

Thank you for your advice from both of you,

I have recreated the old VIPs on new SMO without pushing policy without issues, except one vlan 192.168.99.13/24

Basically the flow during migration is as follows:


What will be tricky is that their management server is in their production VLAN, lets say 192.168.99.0/24.

MGMT IP is 192.168.99.20

Currently the management port of the new ElasticXL GW is in VLAN 192.168.1.0/24.

I need to change this port to vlan 192.168.99.X in order to not be cut off when i turn off the old ClusterXL GWs

Meanwhile i am unable to create these VIP addreses on the ElasticXL since they are used for management port.

After migrating to to ElasticXL i have to create a dummy ip address for management port and then recreate the VIP of VLAN 192.168.99.13

Any advice regarding this?

[emmap]

Can you have LOM or Console access to the SMO gateway during the cutover? If so you can shut the ports to the old cluster, set the IP on the new magg1 interface via LOM/Console and go from there.

[DavidD]

Yes we will have Console access, this was my original plan but @Bob_Zimmerman suggested i could create the same vlan with a fake ip address, and just change the object during failover.

[the_rock]

There was another post on the tool that will be available for it, bit not official yet. Maybe ask your local SE about it.