Network Monitor sees no traffic even though the network interface is receiving a network feed
search cancel

Network Monitor sees no traffic even though the network interface is receiving a network feed

book

Article ID: 163337

calendar_today

Updated On:

Products

Data Loss Prevention Network Monitor

Issue/Introduction

On a Windows or Linux based monitor, you may run into a problem where no traffic is registered by the Vontu Monitor. This can happen even when the NIC card is working fine and traffic is being correctly received by the NIC.

06/02/16 12:50:54 [0x2ab1f30b18e0] INFO  PacketCaptureMain - start() Packet
Capture has started. System Event logged. [PacketCaptureMain.cpp(1832)]

06/02/16 13:00:54 [0x2ab372b29700] INFO  ProtocolManager - No protocol.name.SMTP
Traffic Captured|protocol.name.SMTP traffic has not been captured in the last
00:10:00 seconds. Please check Protocol filters and the traffic sent to the
monitoring NIC.

Jun 2, 2016 12:50:53 PM com.vontu.packetcapture.PacketCaptureConfig waitForLoad
INFO: Received DefaultProtocolFilters.

Cause

Network Monitor supports only one layer of VLAN tags.

Resolution

This problem may be due to nested VLAN tags in the network feed, but can also be due to the issues described in TECH220268

Symantec Data Loss Prevention Network Monitor currently recognizes only one VLAN tag in the ethernet frame, and expects an IP packet after the VLAN tag. In the event multiple VLAN tags are present, Network Monitor only recognizes the first tag and expects to see a properly formed IP packet following the tag. Since for multiple VLANs what follows the first tag are additional VLAN tags instead of a properly formed IP packet, Network Monitor will discard the entire frame as a malformed frame.

The reason Network Monitor supports only one level of VLAN tag is that for most customers, Network Monitor is deployed at the network egress point, before the traffic is sent out to the Internet Service Provider. In such common deployments, the existence of nested/multiple VLAN tags in the network packet are not expected. Consequently, development effort has focused on achieving high performance when processing ethernet frames by not attempting to process additional, unanticipated, VLAN tags.