Orchestrator and EdgeConnect Logging

This document describes how to:

  • Access, export and understand logs generated by HPE Aruba Networking SD-WAN Orchestrator and HPE Aruba Networking EdgeConnect appliances.

  • Use log data for system diagnostics, performance monitoring, and security analysis.

It includes descriptions of syslog exports across different log types for Orchestrator and ECOS running release 9.5 with a Syslog remove receiver.

Terminology

The following table defines terms used in this guide.

Term Definition
Syslog A protocol used to send system logs or messages to a specific server.
JSONify The process of converting data into JSON format for easier parsing and analysis.
Orchestrator Logs Logs that track actions and configurations within the Orchestrator software.
System Logs Logs that record general system operations, like hardware activity or software processes.
Audit Logs Logs that track user actions, changes, and events for accountability and security purposes.
IDS/IPS Intrusion Detection System (IDS) and Intrusion Prevention System (IPS), used to monitor and protect systems against malicious activity.
Firewall Logs Logs that track network traffic that is allowed or blocked by firewall policies.
Severity Levels Log classifications (e.g., Notice, Critical, Warning) that indicate the importance of an event.

Getting Started

Logs are records of events and activities occurring within a system that help users:

  • Diagnose issues, such as system errors or application failures.

  • Monitor performance and ensure system reliability.

  • Identify potential security risks, including unauthorized access or intrusion attempts.

This document is for users who want to learn the basics of Orchestrator and EdgeConnect appliance logs, their types, and how to export them. It provides the following:

  • Instructions for accessing logs on Orchestrator and on EdgeConnect appliances.

  • Explanation of how logs are categorized and their purposes.

  • Sample log entries and field tables that describe the structure and content of logs.

  • Examples of JSONified logs that simplify log data for integration with tools or other analytic platforms.

Log Types

Logs are categorized into Orchestrator Logs and Appliance Logs. Each type serves a specific purpose. The following graphic shows the system integration between Orchestrator and EdgeConnect appliances and where each type of log is generated.

img

Orchestrator Logs

Syslog Logs – These logs are exported from Orchestrator using syslog protocols and contain information about general system operations, user actions, and alarms.

Appliance Logs

  • System Logs – These logs contain information about general system operations.

  • Audit Logs – These logs track user actions.

  • Firewall (FW) Logs – These logs contain information about firewall events.

  • IDS/IPS Logs – These logs track intrusion attempts.

Network Flow Exporting

This topic explains network flow exporting, focusing on the configuration, structure, and behaviour of flow records in protocols such as NetFlow and IPFIX.

Architecture and processes

Flow exporting involves three key processes.

  1. Metering process: Captures packet headers, timestamps, and flow characteristics observed at an Observation Point. It maintains flow records by creating, updating, computing statistics, detecting expiration, and deleting records. These records are passed to the exporting process.

  2. Exporting process: Sends flow records to one or more collecting processes. It handles flow records generated by the metering process and transmits them in IPFIX or NetFlow formats. Flow records contain metadata about network traffic, such as source/destination IPs, ports, ingress/egress interfaces, and traffic statistics.

  3. Collecting process: Receives flow records from exporting processes. It stores or processes the received records for further analysis, such as traffic monitoring, anomaly detection, or performance optimization.

Flow record structure

Flow records contain detailed information about network flows, including ingress/egress interfaces, source/destination IPs, ports, and traffic statistics. These records are stamped based on the selected traffic direction options:

  • WAN_RX (Inbound WAN)
  • WAN_TX (Outbound WAN)
  • LAN_RX (Inbound LAN)
  • LAN_TX (Outbound LAN)

Each enabled traffic direction creates a separate record for the same flow. For example:

  • WAN_TX: in_interface = 0, out_interface = WAN
  • WAN_RX: in_interface = WAN, out_interface = 0
  • LAN_TX: in_interface = 0, out_interface = LAN
  • LAN_RX: in_interface = LAN, out_interface = 0

When all traffic directions are enabled, four records are generated per flow.

Configuration recommendations

  • On Spoke/Client-side exporters, enable WAN_TX. Optionally, enable LAN_TX for efficient flow record generation.
  • On Hub/Server-side exporters, enable WAN_RX. Optionally, enable LAN_RX. This setup is ideal for centralized data collection and analysis.

Optimizations and tools

To analyze flow records and interface details effectively:

  1. Use tcpdump and packet captures to examine exported flow data.

  2. Run the ip link command to retrieve interface indices (ifindex) required for accurate record stamping.

Example scenarios

In a scenario where only WAN_TX is enabled for a LAN-to-WAN flow, a single record is generated with in_interface=0 and out_interface=wan.

Similarly, enabling all traffic types for the same flow produces four distinct records, each corresponding to a specific direction.

Practical implications

The exported flow records are an exact representation of the data captured at the observation point. If specific details, such as ingress or egress interfaces, are missing in the flow details, the corresponding in_interface=0 and out_interface=wan fields in the exported records will also be empty or set to 0. This is particularly relevant for WAN-to-WAN or LAN-to-LAN flows, where interface details may not be available.

Examples

For a LAN-to-WAN flow, enabling only WAN_TX results in one record with in_interface=0 and out_interface=wan. Conversely, enabling all traffic directions generates four records (WAN_RX, WAN_TX, LAN_RX, LAN_TX), each containing the respective interface details.

Conclusion

The integration of NetFlow and IPFIX protocols provides flexibility and granularity in flow exporting. Proper configuration of traffic directions ensures tailored flow record generation for specific network roles (spoke versus hub). Tools like tcpdump and ip link support effective debugging and optimization of flow exporting setups.

Table of contents