Hardware upgrades

[Matthew_Mollenhauer]

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

[emnoc]

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.

[Matthew_Mollenhauer]

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]

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.