NPB GRE/VXLAN Tunnel Encapsulation for Remote Traffic Analysis

With the continuous expansion of network traffic analysis scenarios, it is increasingly common that backend analysis tools cannot be directly connected to NPB (Network Packet Broker). This white paper describes the background, key advantages, working principles, Web‑UI configuration procedures, packet behavior and future feature roadmap of GRE or VXLAN tunnel encapsulation on NPB. It helps users understand and implement traffic distribution solutions based on tunnel encapsulation.

NPB (Network Packet Broker) collects mirrored traffic from production networks, and performs traffic replication, aggregation, filtering and steering, before delivering traffic to backend analysis tools for detection, auditing and signaling analysis.

In typical deployments, NPB is connected to backend analysis tools directly via fiber optics. The production network sends mirrored traffic to NPB through SPAN. After ACL processing, NPB forwards traffic directly to ports connected to analysis tools.

Pain points: Analysis tools must be physically deployed nearby, subject to cabling constraints and physical port limits.

In a growing number of use cases, NPB is no longer physically connected directly to analysis tools. Instead, NPB uplinks to production switches. Mirrored traffic is encapsulated into GRE/VXLAN tunnels inside NPB. Encapsulated packets are forwarded across existing Layer 2/Layer 3 IP networks and finally delivered to remote analysis tools via IP routing.

Analysis tools can be deployed at any remote location with Layer‑3 reachability, free from physical cabling restrictions.

Drawbacks of direct‑attach: Each analysis tool requires dedicated fiber cables from NPB, resulting in extensive jumpers and messy cabinet cabling. Recabling is mandatory whenever tools are relocated, and physical ports on NPB are quickly consumed.

Benefits of tunnel‑based solution: NPB only requires 1‑2 uplink ports connecting to production switches. All mirrored traffic is encapsulated into GRE/VXLAN and forwarded over existing IP networks. Adding, removing or relocating analysis tools requires no physical cabling changes.

Existing production Layer‑3 IP networks can be reused as the traffic transport infrastructure. Extra switches and fiber cables are no longer required, lowering capital expenditure.

This solution fits distributed traffic collection scenarios, such as signaling analysis in railway systems. Each site deploys one NPB collector node. All collectors send traffic back to a centralized analysis platform over GRE/VXLAN tunnels across Layer‑3 IP networks.

Prerequisite: Layer‑3 IP reachability must exist between NPB and analysis tools. This architecture is more suitable for low‑traffic workloads.

NPB receives original mirrored packets (original MAC header, original IP header and payload). Traffic matches ACL forwarding policies, which can be bound to GRE or VXLAN tunnel instances.

Pre‑configure tunnel parameters: source MAC, destination MAC, tunnel source IP, tunnel destination IP, DSCP, VNI (for VXLAN), UDP port, etc.

When packets hit an ACL policy bound to a tunnel, NPB adds tunnel headers to the original payload:

GRE tunnel: Outer Ethernet header + Outer IP header + GRE header. The entire original packet is carried as GRE payload.

VXLAN tunnel: Outer Ethernet header + Outer IP header + UDP header + VXLAN header. The original Layer‑2 frame is carried as VXLAN payload.

Encapsulated egress packets are sent out from NPB uplink ports and routed by switches towards remote analysis tools.

Navigation path: Forwarding Policy → Global Config → Tunnel Header

1. On the Tunnel Header page, click Add to create a new tunnel configuration.
2. Fill in tunnel parameters:
   • Name: Custom tunnel identifier
   • Type: Select tunnel type: GRE / VXLAN
   • IP Version: IPv4 / IPv6
   • Dst MAC: Peer device MAC address (mandatory)
   • Src MAC: Tunnel source MAC. Defaults to NPB’s system MAC and is editable.
   • Src IP / Dst IP: Tunnel source IP and tunnel destination IP
   • DSCP: DSCP marking for outer IP packets
   • VLAN: Optional. Add outer‑layer VLAN tag for tunnel packets
   • VNI (VXLAN‑only): VXLAN network identifier
   • Src Port / Dst Port (VXLAN‑only): VXLAN UDP ports. Standard port is 4789.
3. Save settings to complete tunnel creation.

Important Constraints

1. Existing tunnel configurations cannot be modified in‑place. To change parameters, delete the old tunnel and create a new one.
2. Before deleting a tunnel, remove its binding from forwarding policies; otherwise deletion will fail.

1. Navigate to Forwarding Policy → Policy.
2. Create or edit a forwarding policy.
3. In the policy setting Encap Name, select the pre‑created tunnel instance from the dropdown list.
4. Save the policy.

Behavior: All packets matching this forwarding policy will be encapsulated with the selected tunnel headers and transmitted.

Packet comparison via Wireshark between original packets and encapsulated packets:

Original: Ethernet → VLAN → IP → UDP → Business Payload

GRE‑encapsulated: Outer Ethernet → Outer IP → GRE header → Complete original packet (original Layer‑2, IP and payload preserved).

Original: Ethernet → VLAN → IP → UDP → Business Payload

VXLAN‑encapsulated: Outer Ethernet → Outer IP → UDP(4789) → VXLAN header → Complete original Layer‑2 frame.

The original user‑plane payload remains unchanged and fully preserved inside the tunnel payload.

Destination MAC is manually configured in the current release. Planned enhancements for future versions:

1. Specify tunnel next‑hop IP with auto MAC learning: Users input next‑hop IP only; the device resolves peer MAC via ARP to reduce manual configuration.
2. Packet fragmentation: Handle MTU fragmentation for tunnel‑encapsulated packets to avoid drops caused by oversized frames.
3. Multi‑tunnel load balancing: Distribute traffic across multiple tunnel instances under one forwarding policy for load‑sharing.
4. NVGRE tunnel support.

GRE/VXLAN tunnel encapsulation on NPB transforms traditional physical direct‑attach traffic distribution into IP‑tunnel‑based forwarding.

• Resolve pain points including limited tool deployment locations, complex cabling and physical‑port exhaustion.
• Reuse existing production Layer‑3 networks to lower total deployment costs.
• Well‑suited for distributed multi‑site collection with centralized traffic analysis.

Operators can provision services by creating tunnel instances on Web‑UI and binding tunnels to forwarding policies. Future software releases will continuously improve configuration experience and add fragmentation, load‑balancing and NVGRE capabilities to extend applicable scenarios for NPB tunnel encapsulation