Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Matthew_Mollenhauer
New Contributor III

Hardware upgrades

Does anyone know how the Fortigates session tracking works when an interface is first brought up? I ask as we' re about to do a forklift upgrade of our Production sites from a 1240B HA Cluster to a 1500D HA cluster. We' re using a FortiManager to take care of policies and control device settings, it' s also from there that we' ll do the switch over. My current plan has the new cluster fully configured with all of it' s interfaces shutdown. Once ready from the FMG I' ll set all interfaces on the old cluster to be shutdown & and all interfaces on the new cluster to be up. And it' s a simple matter of deploying to both units at the same time. Previous rehearsals in our DR environment aren' t a good indicator of behaviour as it has such a low traffic rate. But having said that most of our applications that maintain persistent connections seemed to handle the cutover without requiring a restart. This suggests to me that when the an interface comes up the firewall doesn' t check it' s session tracking tables for traffic ingressing from that interface. A review of our logs also didn' t show the usual " no matching session" logs. So as originally asked, does anyone know how the Fortigates handle this? Some doco from Fortinet on doing a hardware upgrade/refresh would also be nice... Regards, Matthew Mollenhauer
3 REPLIES 3
emnoc
Esteemed Contributor III

Think about this for a moment, if a previously down interface should come up, than what/why would fortigate check it' s session table? It has nothing new to check. Q: Are you trying to conduct a hit-less migration into the new clusters? If the answer is a yes, then I don' t think it' s possible. I would suspect high delay and some applications might need restarting or possible client timeouts imho. Also tcp is connection-orientated, so i don' t see how persistent connection will resume without some type of interference. imho & from experience, if you want to minimized the later, shutdown all server-side applications and restart them after the new cluster is up. If you have a DR-site 100% available, you could even swing the active-DC to the DR-site, bring up the new cluster. Run some testing & swing back imho. Just put this step into your Migration Plan & update your clients on a potential outage due to DC improvements.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Matthew_Mollenhauer
New Contributor III

Hi Emnoc, Thanks for the reply, for us the answer isn' t exactly an easy solution. As a bit of background our site is primarily e-commerce, around 140 servers with over 60 different applications (with at least two instances of each app). A full site shutdown isn' t feasible, even if our management agreed to let us do it. While our DR site is a full replica of production, management are extremely reluctant to even consider a failover, majority of the time it is used as perf test environment and isn' t suitable to take a production load. This is a sore point for us in Ops, we want to run out of DR on a regular basis but alas we can' t. But from my own testing/rehearsal I didn' t see a major impact when doing the switchover in DR. I actually had a SSH connection to a few servers in that environment, all of which maintained the the ssh session. This is one of the reasons I asked the question, it shouldn' t have been like that if the new cluster was looking at it' s empty session table. There are two things that are in our favour; the majority of our apps do connection validation, so they will reconnect if a connection is broken. Currently we know of four apps that don' t do this properly and we can restart them quickly. And the second thing that actually assists the first is that we have reset-sessionless-tcp enabled. I was hoping the cluster would operate in a manner similar to a VRRP failover where the unit would go into async routing mode so it could learn it' s session table without killing existing sessions. I could also see another scenario where this could happen; A Fortigate operating as an inter-site router using a dynamic routing protocol, eg; OSPF. A WAN link goes down (physically) and traffic reroutes over a different path, when the link comes back OSPF would re-advertise the path and existing sessions would be thrown back at the Fortigate. In any case, thank you for your feedback. Either way I' ll be ensuring I have some admins and tester on hand when we do the switch over. Regards, Matthew
emnoc
Esteemed Contributor III

The letter might be feasible but you still have the same issues. The new cluster won' t have session sync from the old cluster. So you have two issues to contain one is already addressed; 1: session reset or re-pickup from the server +client 2: new sessions population on the new cluster Using routing protocol and if your new and old cluster are on " Tertiary" link, you could just manipulate the route path ingress/egress and let the new cluster learn the sessions. The clients would perform their re-pickup and continue on. Do you have any SLB issues to contended with ? Please see drawging on how you can manipulate this via a dynamic routing protocol.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Top Kudoed Authors