Recently a customer told me he would like to monitor and graph the values that his Fortigate Firewall was generating for his configured SLA Trackers. What are these SLA Trackers? I informed myself and found the following in a Fortigate Cookbook.
Fortigate Performance SLA ─ Link Monitoring
Performance SLA link monitoring measures the health of links that are connected to SD-WAN member interfaces by sending probing signals through each link to a server, and then measuring the link quality based on latency, jitter, and packet loss. If a link is broken, the routes on that link are removed, and traffic is routed through other links. When the link is working again, the routes are then re-enabled. This prevents traffic being sent down broken links and thus lost.
In the example above:
Interfaces wan1 and wan2 connect to the internet through separate ISPs
The detection server IP address is 199.199.199.199
A performance SLA is created so that, if one of the two links fails, its routes are removed and traffic is detoured to the other link.
Getting Data for Fortigate SLA Trackers
Configuring such trackers will produce basically 3 values:
Network Latency
Network Jitter
Network Loss
This data can be queried from the device using SNMP (on the Fortigate it’s SNMPv3) and using the following base OID: 1.3.6.1.4.1.12356.101.4.9.2.1
Starting from there you have to walk various trees to get the correct and complete data:
1.3.6.1.4.1.12356.101.4.9.2.1.2: This is the location identifier for which various interfaces are used as in the example above
1.3.6.1.4.1.12356.101.4.9.2.1.14: This is the interface name OID, and has to be used together with the location identifier to obtain a unique identifier
1.3.6.1.4.1.12356.101.4.9.2.1.5: Latency value for any location/interface pair
1.3.6.1.4.1.12356.101.4.9.2.1.6: Jitter value for any location/interface pair
1.3.6.1.4.1.12356.101.4.9.2.1.9: Loss value for any location/interface pair
With this knowledge it was quite easy to write a small plugin to use with the Icinga 2 instance in our NetEye Server. You can download the code for the plugin here: check_snmp_fortigate_sla_tracker.pl
Now you just have to get the values you need for the SNMP connection to your firewall (protocols 1, 2c and 3 are supported), and then call it like this:
The Warning and Critical parameters are a triple of latency, jitter, loss. Any reported values from any of the interfaces must be below these configured values in order to not trigger a warning/critical event.
These Solutions are Engineered by Humans
Did you read this article because you’re knowledgeable about networking? Do you have the skills necessary to manage networks? We’re currently hiring for roles like this here at Würth Phoenix.
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix. Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Author
Juergen Vigna
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix. Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Today I want to present an Icinga 2-based monitoring use case where concepts of the powerful Icinga 2 DSL functional language come into play. The use case is based on mapping the status of a Host/Service Object via passive check Read More
Director is one of the most important modules in NetEye 4 because it's used for managing, automating and deploying the configurations of all monitored objects. In all our projects we use automation in Director: through the Import and Synchronization rules Read More
The performance graphs present in NetEye are very useful for getting an immediate idea of the trend related to a service check, but they're still limited to the metric being viewed. Also, the "Show all graphs" option available from the Read More
(Or, Who's Monitoring the Monitor?) Everyone uses a monitoring system to understand what's going on in their own environment and how it performs, but what about the monitoring system itself? The monitoring system also has its own tasks to perform, Read More
SOAP is a messaging protocol for exchanging information based on XML over the network. SOAP messages are written in XML, which is why they are platform- and language-independent. A lot of enterprises have such webservices that return useful data for Read More