• Missing Items: This arises when the Bill of Materials (BoM) or list of elements to be used on the project lacks an item. Sometimes, it is a license or a contract. An example is support. If you need a contract that lists an Advanced Replacement/24 × 7 option, and you have Return and Replace/8 × 5, problems can arise. Sometimes, you will experience hardware issues, such as needing additional hard disks or connectors. These missing items result on additional expenditures, pushing you past your budget.

• Suggestions to avoid it: The best way to avoid this issue is to plan and do a test run in advance. Do this with at least two different people (the 4-eye principle). A good way to avoid surprises here is to have diagrams illustrating physical connections of all the boxes. This way, missing elements as switches, connectors, or modules may become clear. Also, review contracts and ask in advance: “what’s the worst situation I could face here”? Do the contracts provide the coverage I need for this environment and its potential failures?

• Suggestions to address it: This is probably the hardest situation you can find, because if you missed your opportunity to request budget for something that is required. However, you have a few options.

- Find a Substitute: Sometimes you may have a spare item somewhere else in the network which can be reused for this project. You might also try to find something that could do on a temporary basis, while you find budget to purchase what you need. A Hard Disk module from another FortiGate that only logging could give you the module, you need to perform WAN Optimization. Another FortiGate might have the fiber transceiver you need and be more feasible to switch from copper to fiber.

- Use another element in the network: Even though it is not desirable, sometimes you can shift workload to other network elements: an additional VLAN could be implemented on a switch or an additional VDOM on an existing FortiGate.

- Change the scope: You can always evaluate the impact of not having the missing piece, and change the expectations to fit the new situation. For example, if you missed the 24 × 7 support option, some processes could be adopted to ensure support calls would be done only within business hours, and select maintenance windows such that they would fall within business hours. Note: this is seldom possible.

• Undersized models: It is sadly common for people to undersize their FortiGate selection. They say the project scope is only Web Content Filter + Antivirus, and end up also enabling QoS + Application Control. Perhaps, the number of users is estimated at 2000 with three connections each, but in there are actually 2500 users opening 10 connections each that need inspection. This results on having to spend additional money to upsize the box.

• Suggestions to avoid it: This has been addressed by earlier chapters. However, the final two pieces of advice: (1) Always size thinking all the FortiGate features will eventually be enabled. (2) If in doubt, go bigger: it is cheaper to request and spend additional money in the beginning than to attempt to replace a device later.

• Suggestions to address it: If the device cannot be replaced with a bigger one, three things should be considered: (1) Maximize performance tuning by leveraging ASICs as much as possible, adjusting content inspection (IPS, WCF, AV) profiles and reducing firewall policies. (2) Reduce load by disabling functions such as routing traffic that needs IPS inspection to another system and disabling IPS on the FortiGate. (3) Do the project in phases and plan to move load to older boxes until they can be replaced.

• Change of scope: If the project changes its scope and fewer things that must be accomplished, there is seldom an issue. However, if scope is increased to cover for additional items (more functionality, users, or services) this might affect not only the sizing of the FortiGate, but also the amount of time and human resources needed for the project, adding cost.

• Suggestions to avoid it: The planning phase of the project should consider potential changes of scope and, where possible, associated cost. The best way to do this is to carefully review concurrently running projects and assessing overlap or complementation of the project at hand. This might be difficult, but by looking on what you are trying to achieve, the people involved and services to be offered, it may be easier to ascertain this information.

• Suggestions to address it: Since change of scope will often result in an undersized FortiGate, the earlier advice also applies. A phased project approach is often the best, as the expanded scope can be done in a second phase after the first has been completed, tested, and placed into full production.

• Parallel Activities: While this is often planned from the beginning, a careful assessment should be done with the objective of identifying activities that can be performed in parallel, perhaps by different teams. This can result in dividing the current people engaged into the project. This also will require an additional activity (analysis), but as the people doing that already some experience in the project itself, this might help to identify optimizable activities.

• Adding people: Consider adding people to the project team. However, even if the people being incorporated have the right technical skills and knowledge to help, this option does add additional overload, as those people must be brought up to speed.

• Avoid or postpone steps: There are often activities that can be eliminated or postponed, but doing so may carry risk. An analysis could be conducted to determine if some activities are subject to removal, reduction, or postponing. The most tempting tasks to be eliminated are in the Quality Assurance (QA) phases. However, this often adds substantial risk and should only be considered as a last resort. Postponing documentation activities is less risky, but only so long as the documentation is eventually done.

a. Define the issue in a clear and specific way. Remember that problems are contradictions between what you want and what you have. State what you want in a way that can be measured, and then state what you currently have. In other words, make sure the description of the problem has a specific “What”. “The FortiGate is failing” and “IPS is not working” are overly vague statements. However, “IPS is not catching a SYN Flood attack”, “IPS signature X is not catching traffic that should match it, ” “When I enable IPS my latency increases from 5 to 7 milliseconds, ” and “My throughput drops by 50% when I enable IPS” are statements that can be proven. One of the best ways to test an accurate statement is to ask to describe the problem to a coworker and verify that they understand it in the same way you do.

b. If you can replicate the issue, indicate the steps to do so. The most difficult problems to fix are those that cannot be reproduced. One of the first things that you should mention is whether you can cause the problem to occur. If so, make sure you list the steps to do so, including sequence and duration of the steps. By reproducing the problem, a technical support engineer can use Fortinet’s equipment to replicate the issue, isolate it and test the potential fix without affecting your environment. If the problem cannot be reproduced, it may be necessary to wait for reoccurrence of the problem to capture additional information to isolate and diagnose the issue.

c. Indicate your findings. If you have already tried remediation steps that didn’t work, tell the TAC what you tried. This way, you maximize both your time and theirs. Indicate both what you did and what the result was. If possible have copies of the output so the engineer can see the results.

d. Clearly Communicate importance. TAC engineers get many calls every day. Some relate to minor issues. Some of them relate to customers who use a FortiGate as a highly critical component. If your ticket is critical, explain this to the TAC to get appropriate priority.

e. Clearly communicate contact information. Make sure appropriate names, e-mails, and cell phone numbers (including country code and city code) are posted in the ticket. If possible, this information should include remote access credentials to the FortiGate. By allowing the TAC engineer to connect to the FortiGate, even in read-only mode, they will better understand the environment and the nature of the issue.

f. Ask for remote assistance during maintenance windows. Depending on the support contract you purchased, you may be entitled to ask for remote support during maintenance windows. This way, the TAC engineer can remotely connect and collect troubleshooting information, without having to request it from you.

g. All in all, communication is important to ensure TAC engineers have all the tools to help you determine the problem. Also, never assume anything. If you doubt the TAC engineer understood what you were trying to say, it is better to confirm than find out later there was a misunderstanding. Every misunderstanding will just add unproductive time to the equation.