Troubleshooting:

o Troubleshooting is being able to analyze the problem, determine the cause of the error.
o Troubleshooting is basically implementing a plan of action and resolve the network issue.
o Troubleshooting is combined measures & processes used to diagnose & solve problems.
o Troubleshooting is logical process that network engineers use to resolve network problems.
o Troubleshooting is logical process that network engineers use improve network operations.
o Troubleshooting is basically iterative process, the more data you collect, gather and analyze.
o More data collect and analyze the higher the likelihood of developing a correct hypothesis.
o It is systematic process aims to resolve problems and restore normal network operations.
o The Process of detection, minimization and resolving the faults that arise in the network.

Problem Isolation:
Determining at what layer of the OSI model & on what devices and links the problem may exist.

Documentation:
It is critical to document the processes you use and the information you find; it can not only
help you in the current process but can become critical for those that troubleshoot after you.

Resolve:
Find the root cause of the problem after your problem isolation process, you document what
has happened, and then you fix the root cause of the problem; fixing the problem is what is
meant by resolving the problem.

Escalate:
Should you not be able to fix the issue, there should be a written escalation process in your
organization; this might involve even communicating to a third party that your company
partners to fix the issue.

Verify and Monitor:

Many times, it might take time to carefully verify and monitor your solution to ensure the
issue(s) are truly resolved. When a problem has been solved and a solution implemented, it is
important to verify the system operation. Verification tools include the ping, traceroute &
show commands. The OSI model is a critical tool when carrying out your troubleshooting.

1 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717

Ping and Traceroute Commands:
Ping and Traceroute are useful tools in network troubleshooting. Both tools accept either IP
addresses or fully-qualified domain names as parameters. This can help you determine why
particular services, such as email or web browsing, are not working properly. Both ping and
traceroute require particular ports to be open on firewalls to function. Since you typically
use these tools to troubleshoot, you can allow them in the firewall policies and on interfaces
only when you need them, and otherwise keep the ports disabled for added security.

2 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717

T-Shoot Different Approaches:
Top-Down Approach.
o Start at the top of the OSI model (Application Layer) and down to the bottom.
o The idea is that we will check the application to see if it is working or not working.
o Assume that if a certain layer is working that all the layers below are also working.
o Send ping from one computer to another assume that layer 1, 2 and 3 are operational.
o The downside of this approach need access to the application that troubleshooting.

Bottom-Up Approach.
o Start at the bottom of the OSI model (Physical Layer) and we will work our way up.
o Start with physical layer; check the cables and connectors, move up to data link layer.
o Check Ethernet is working, Spanning-tree is working ok, port security is not causing issue.
o Check VLANs are configured properly and then move onto the network layer of OSI Model.
o At Network Layer (Layer 3) check IP addresses, access-lists, routing protocols and so on.
o This Bottom-Up Approach method is very thoroughgoing but also time-consuming.
o This Bottom-Up Approach method is very good for new troubleshooter Engineer.
o Because in this approach you will eliminate all the possible causes for problems.

3 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717

Divide and Conquer Approach.
o Divide and Conquer Approach start in the middle of the OSI Refence model.
o This model is good if not sure if top-down or bottom-up are more effective.
o Divide and Conquer idea is that try to send a ping from one device to another.
o If the ping works you know that layer, 1-3 are operational & work up in OSI model.
o If ping fails, something is not right and work way to the bottom of the OSI model.

Follow the Traffic Path Approach.

o The follow the traffic path Approach method is very useful and Convenient.
o First, try to send a ping from the source device to the end destination device.
o If it fails, check all the devices coming in the path of source and destination devices.
o First, verify if SW1 is configured correctly, if good move onto SW2 & then move to R1.

Spot the Difference Approach.

o Comparing a Working and Nonworking Situation and Spotting Significant Differences.
o The Network engineers that do not have a lot of experience usually use this approach.
o Problem might solve but there is a risk that you do not really know what you are doing.

Replace Components Approach.

o The last approach to solve the problem is to replace components Approach.
o Swapping Problematic Device with a Known, Working One to Troubleshoot.

4 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717

 Determine the Scope of Limited
Top-Down Method
the Problem

Analyze the Symptoms Bottom-Up Method

Apply Previous Divide-and-Conquer

Experiences Method
Experienced Before

Comparing a Working & Nonworking Situation, & Spotting Significant Differences

Swapping Problematic Device with a Known, Working One to Troubleshoot

5 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717

 For better Tshoot Clock Setting is correctly, NTP is working properly, Syslog server
is configure remotely or in the device, SNMP server is configure, and regularly
take Device Backup within the device and remotely in the network.

6 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717

Packet Sniffing:
When you troubleshoot networks and routing in particular, it helps to look inside the headers
of packets to determine if they are traveling the route that you expect them to take. Packet
sniffing is also known as network tap, packet capture, or logic analyzing. Packet sniffing can tell
you if the traffic is reaching its destination, what the port of entry is on the FortiGate unit, if the
ARP resolution is correct, and if the traffic is being sent back to the source as expected. Packet
sniffing can also tell you if the FortiGate unit is silently dropping packets.

diagnose sniffer packet <interface_name> <‘filter’> <verbose> <count> <tsformat>

To stop the sniffer, type CTRL+C.

<interface_name> The name of the interface to sniff, such as port1 or internal. This can also
be any to sniff all interfaces.
<‘filter’> What to look for in the information the sniffer reads. none indicates no
filtering, and all packets are displayed as the other arguments indicate.
The filter must be inside single quotes (‘).
<verbose> The level of verbosity as one of:
1 - print header of packets
2 - print header and data from IP of packets
3 - print header and data from Ethernet of packets
4 - print header of packets with interface name
<count> The number of packets the sniffer reads before stopping. If you don't put
a number here, the sniffer will run until you stop it with <CTRL+C>.
<tsformat> The timestamp formats.
a: absolute UTC time, yyyy-mm-dd hh:mm:ss.ms
l: absolute LOCAL time, yyyy-mm-dd hh:mm:ss.ms
otherwise: relative to the start of sniffing, ss.ms

diagnose sniffer packet port2

diagnose sniffer packet port2 ' host 192.168.1.1 '
diagnose sniffer packet port2 ' host 192.168.1.1 and host 8.8.8.8 '
diagnose sniffer packet port2 ' host 192.168.1.1 and port 80 '
diagnose sniffer packet any ' host 192.168.1.1 '
diagnose sniffer packet any ' host 192.168.1.1 or host 8.8.8.8 '
diagnose sniffer packet any ' host 192.168.1.1 or host 8.8.8.8 ' 4 10
diagnose sniffer packet any ' host 192.168.1.1 or host 8.8.8.8 ' 4 0 a
diagnose sniffer packet any ' src 192.168.1.1 '
diagnose debug disable
diagnose debug reset
diagnose debug flow filter addr 192.168.1.1
diagnose debug flow filter port 80

7 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717

Fundamental CLI Commands:

Commands Description
get sys status Check the system status
get system performance status Check the hardware performance
get system performance top Check the hardware performance
get hardware memory Displays information about memory
diag sys session full-stat Check the session table of the firewall
diag sys session list Check the session table of the firewall
get system session status Displays total number of sessions
get system interface physical Check the interface settings
diagnose hardware deviceinfo nic internal Check the interface settings
get system arp Check the ARP Table
execute clear system arp table Clear ARP Table Entries
get router info routing-table all Check the Routing Table
get router info routing-table details Check the matching route
192.168.2.0
diag vpn tunnel up phase2-name phase1- Change the tunnel state
name
diag vpn tunnel down phase2-name phase1-
name
diagnose vpn tunnel list name myphase1 Check the tunnel state
diag vpn tunnel dumpsa
diagnose vpn tunnel stat
diagnose vpn ipsec status Check packet counters for the tunnel
diag vpn tunnel list
diagnose sniffer packet Tshoot Diagnose Commands
diagnose sniffer packet any
diagnose sniffer packet any none
show full-configuration Check Full Commands List
execute reboot Reboot Forigate Firewall
get router info routing-table all Display Routing Table details
diagnose firewall proute list
execute ping Send Ping packets
show system dns Displays configured DNS servers

8 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717

Basic CLI Configuration Commands:

Configure Hostname
config system global
set hostname FG-FW
end
Configure Interface
config system interface
edit port2
set allowaccess ping
set ip 192.168.1.100/24
set alias LAN
Configure DNS
config system dns
set primary 8.8.8.8
set secondary 1.1.1.1
end
Configure Route
config router static
edit 1
set dst 0.0.0.0/0
set gateway 192.168.114.2
set distance 10
set device port1
end
Configure Packet Capture
config firewall policy
edit 1
set capture-packet enable
end

9 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717

Configure Packet Capture:
Go to Network > Packet Capture. When you add a packet capture filter, enter the following
information and click OK.

Interface Select the interface to sniff from the drop-down menu.

You must select one interface. You cannot change the interface without
deleting the filter and creating a new one, unlike the other fields.
Max Packets to Enter the number of packets to capture before the filter stops.
Save This number cannot be zero. You can halt the capturing before this number
is reached.
Enable Filters Select this option to specify filter fields.
Host(s) Enter the IP address of one or more hosts.
Separate multiple hosts with commas. To enter a range, use a dash without
spaces. For example, 172.16.1.5-172.16.1.15, or enter a subnet.
Port(s) Enter one or more ports to capture on the selected interface.
Separate multiple ports with commas. To enter a range, use a dash without
spaces, for example 88-90.
VLAN(s) Enter one or more VLANs (if any). Separate multiple VLANs with commas.
Protocol Enter one or more protocols. Separate multiple protocols with commas. To
enter a range, use a dash without spaces. For example, 1-6, 17, 21-25.
Include IPv6 Select this option if you are troubleshooting IPv6 networking, or if your
Packets network uses IPv6. Otherwise, leave it disabled.
Include Non-IP The protocols in the list are all IP based except for ICMP (ping).
Packets Use this feature to capture non-IP based packets. Examples of non-IP
packets include IPsec, IGMP, ARP, and ICMP.

10 | P a g e Created by Ahmad Ali E-Mail: ahmadalimsc@gmail.com , Mobile: 056 430 3717