SD-WAN Network Monitoring

A very common monitoring scenario is SD-WAN network performance monitoring. There are two main use-cases for SD-WAN monitoring, the first one being SD-WAN migrations and the second being the monitoring of an SD-WAN service, including the individual connections. This article will cover both of them.

SD-WAN migration monitoring is a very simple use-case which requires no special configuration. The only thing you need to do is to begin monitoring before the migration occurs to leave enough time to collect useful data to compare with after the migration.

The configuration is straight forward. Deploy one agent at the Branch Office and one agent at the Datacenter. Then, configure one Network Monitoring Session between them and wait to collect data. No special configuration is required because it is SD-WAN. Detailled instructions on how to do a basic setup are available in the Onboarding Tutorials.

For networks using QoS (Quality of Service), it is possible to monitor each class of service using DSCP codes. With this configuration, you can compare QoS on a private MPLS network versus SD-WAN QoS. More details are available in the QoS Monitoring Documentation.

In this example, the branch office migrated from a dedicated low-bandwidth MPLS connection to an SD-WAN service with two brandband connections. The migration occurred in the middle of the graph (around 18:20). A few minutes later, around 19:00, the SD-WAN service switched from the primary ISP to the secondary ISP due to high packet loss for about 15 minutes. There is just a little bit of packet loss during the failover because it took a few seconds for the SD-WAN appliance to failover.

When monitoring SD-WAN, it's important to monitor the real end-user network performance but also the performance of each WAN connection on the SD-WAN appliance.

Without the monitoring of each WAN connection, problems can occur on one connection but never affect the end-users until the primary connection has issues and then the end-user network performance is impacted. It is also by comparing the data from each WAN connection that you can then appreciate the value of the SD-WAN appliance.

The setup to monitor an SD-WAN network is a bit more complicated than the migration and requires some special configurations. Similar to the migration example above, the network monitoring sessions will be between two locations, a branch office and a datacenter. The goal here is to have 3 monitoring sessions:

• Branch Office to Datacenter through SD-WAN Load Balancing
• Branch Office to Datacenter through ISP A
• Branch Office to Datacenter through ISP B

The best way to achieve this is to use 3 agents at the datacenter that have 3 different IPs. It's important to use 3 agents that are located at the same place to reduce the impact of other network issues that can happen between the branch office and the datacenter. In this example, the 3 agents are:

• Datacenter through SD-WAN Load Balancing (IP 203.0.113.100)
• Datacenter through ISP A (IP 203.0.113.101)
• Datacenter through ISP B (IP 203.0.113.102)

This example is using Public IPs because it is the simplest configuration. More details on how to use internal private IPs is explained later in this article. The IPs are fake and only used for documentation purposes (see RFC5737 - TEST-NET-3). You must use your own IPs.

On the SD-WAN appliance at the branch office, no special configuration is required for the first agent because it must take the same network path as the end-user real traffic. For the two other agents, static routing is required:

• Force all traffic to 203.0.113.101 through ISP A
• Force all traffic to 203.0.113.102 through ISP B

It is also recommended to disable failover for the two IPs above. This way, if there is a complete outage on one WAN connection, 100% packet loss will be reported, which is exactly what is happening.

In the example above, the top graph is the real network performance for the branch end-users. There are 3 connection changes in that example:

• A bit after 18:00: congestion on ISP A, failover to ISP B after a few seconds;
• Around 18:20: congestion disappear, back to ISP A;
• A bit before 20:00: packet loss and higher latency/jitter on ISP A, failover to ISP B.

Is it possible to use Public Monitoring Agents instead of the agents installed at the datacenter? The answer is probably no because most of the public monitoring agents operated by Obkio don't have static IPs. The IPs don't change a lot but they can change.

That beging said, for Enterprise Customers, special public monitoring agents with static IPs are available for exactly that use-case. Talk to your solution architect about this option.

Instead of using public IPs, it is possible to use private internal IPs. The challenge with private IPs is the reverse path, meaning the path from the datacenter to the branch office. Some SD-WAN appliances offer Sticky Connections which will use the same SD-WAN internal tunnel for the return traffic that was used for the incoming traffic. If this feature is available, just enable it and the setup should work. Otherwise, some static routing can be considered.

The use of the special public monitoring agents with static IPs mentioned in the section above is the preferred option for many customers because routing flexibility is not available with their SD-WAN appliances or because of the complexity of their SD-WAN network.

Note: As usual, all the agents must be in the same Agent Network to use private IPs.

Also take a look at our blog posts about SD-WAN monitoring:

• How to Monitor SD-WAN Migrations
• How to Monitor SD-WAN Networks