📘

Most used tab for troubleshooting any traffic going over the fabric!

1. Able to see “one way” flows (server/client not responding/traffic dropped)
2. Able to see route/Segment/ZBFW dropped traffic in the fabric
3. Able to see Boost performance (if licensed and configured)
4. Use Flow detail to confirm routing/boost/NAT/FW Zones and Segment
5. Fine granularity on Filtering for traffic.
6. Ability to save frequently used filters
7. Yellow indicates suggested basic search fields and settings.
   1. Setting "Bytes" to total is helpful to prevent confusion when looking at longer living flows. and when troubleshooting one way flows(below)

📘

Can select multiple EC in the left tree to view cross fabric flows at the same time!

This allows you view the flow from:

1. Datacenter/hub to the Spoke
2. Spoke to Spoke in a mesh network
3. Spoke > Hub > Spoke in Hub and Spoke (example below)

👍

Traffic you filter for all the time? Save a filter !

1. Filter Drop down includes built in and custom filters
   1. Add custom filters, filter for the traffic you want, then click edit type filter name
   2. click +Add
   3. Click save

2. Flow Filter is now in quick access drop down

Note: no fields are mandatory “application: Googlesheets” is just an example. you can get very granular to find your traffic. - This is why saving a filter is very helpful to prevent having to type out/remember every time you need to find this traffic.

Checkbox for Src:Dst IP address/Port

👍

Note flow direction (perspective)

OUTBOUND = From LAN > To WAN
INBOUND = From WAN > To LAN

📘

One way flows, why they are important! Usually show a possible problem! Example:

1. We see that 10.60.0.1 is a healthy flow (yellow), if traffic is not returning to the EC most likely the loss/block is external to the Edge Connect Fabric (RED).
2. In this case “10.60.0.2” does not exist but let’s assume it is just server we are trying to reach.
   1. Using the flow direction above we see inbound traffic from the WAN and no outbound traffic(red) to the WAN
   2. We did not receive and return traffic on the LAN to our ICMP ping. So, we have no return traffic to send to the WAN.
      1. Device off the network
         1. Vlan mismatch/trunk config
         2. IP config error
         3. Power
      2. Security policy
         1. LAN Firewall
         2. Client Firewall/security agent
      3. Routing
         1. LAN routing
            1. No return route to EC
            2. incorrect return route - send away from EC
3. Critical to understand this – to outside groups it looks like an issue with the EC/SD-WAN Fabric but is a LAN/endpoint issue.
4. Can confirm with EC packet capture.

Flow detail

Note: Flow direction - It is a little confusing

Route section

Train your eyes to the Information in the yellow boxes below.

1. Flow Direction = Inbound (came from tunnels/WAN)
2. WAN Routing = none (no packet came back so no routing)
3. LAN routing = ARP (The EC sent a "who has 10.60.0.2" ARP message out LAN0)

Stats section

1. Inbound LAN packets & Inbound WAN packets (showing 1 packet)

   1. This packet is coming from tunnels (from WAN) and going to the LAN - as shown above, this packet is dropped because ARP is failing.
   2. From the LAN port level - yes- this "outbound" but our system always uses the higher level perspective above.

2. The Outbound LAN/WAN - the LAN port is waiting on the return flow/packet (to send to the WAN) but no packet arrives. Because no device is replying to ARP messages we can conclude the problem exists on the LAN/client as outlined above.

   1. 

      This can be confirmed with TCP dumps (above example) or packet captures in the following guide pages.

👍

Zone filter: must select segment (segment cannot be “any”)

More Flow References

Flow Video Series