| Description |
This article describes that the Microsoft Azure Linux Agent (waagent) manages Linux and FreeBSD provisioning and VM interaction with the Azure Fabric Controller.
(For more information, refer to https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/agent-linux).
FortiGate deployed in Azure is equipped with Microsoft Azure Linux Agent during installation. It is possible to find out that the Microsoft Azure portal complains that the virtual machine agent is not ready and requests to troubleshoot the issue:
 |
| Scope | FortiGate Azure. |
| Solution |
When this issue happens, it usually indicates a problem with connecting to the Azure Fabric Controller (168.63.129.16). It is possible to confirm that with the following steps:
1) To check the connectivity between FortiGate virtual machine agent and Azure Fabric Controller, run the following command:
# diag deb app waagent -1 # diag deb en # diag test app waagent 1
It is noticed that the virtual agent is trying to connect to Azure Fabric Controller IP 168.63.129.16 and the connection did not manage to go through.
2) Run the debug flow to check on the traffic flow:
# diag deb flow filter addr 168.63.129.16 # diag deb flow sh function-name en # diag deb flow sh iprope en # diag deb flow trace start 20 # diag deb en
From the above debug flow, it is possible to see that the traffic towards Azure Fabric Controller is being forwarded to port2 which is supposed to be meant for the internal network traffic.
3) Check the routing table for 168.63.129.16 with the following command: get router info routing-table details 168.63.129.16.
It was noticed that there is a static route configured to route traffic destined to 168.63.129.16/32 to port2.
4) Azure Fabric Controller IP is considered as an external IP from FortiGate point of view. Hence, the traffic should be exiting using port1 instead of port2.
In the above scenario, removing the static route and reinitiating waagent connection would resolve the issue.
Recheck the connection with the following command, and it will be possible to see that waagent is now communicating with Azure Fabric Controller successfully:
# diag deb reset # diag deb app waagent -1 # diag deb en # diag test app waagent 1
5) Once the waagent is able to send the traffic towards the correct interface, the agent status and host details will be appearing in Azure console respective:
The connection between Microsoft Azure Agent and Azure Fabric controller would not impact FortiGate performance. There is no downtime required to perform the above remediation steps.
If External Load Balance or Internal Load Balance is used, the connection of the virtual machine agent will be transmitting on both port1 and port2. Hence, 2 static routes would be required:
# config router static
For more information on deploying the FortiGate with ELB/ILB scenario, please refer to the following document: |
