Support for LLDP / PN-DCP device discovery (e.g., Siemens devices)

[983674707]

Hi,

I would like to ask whether n3n currently supports device discovery using LLDP or PROFINET DCP (PN-DCP).

In some industrial network environments (especially with Siemens PLCs and other PROFINET devices), devices are often discovered using:

• LLDP (Link Layer Discovery Protocol)
• PN-DCP (PROFINET Discovery and Configuration Protocol)

PN-DCP works at Layer 2 and uses Ethernet multicast to discover devices within the local subnet. It is commonly used to identify and configure Siemens PROFINET devices.

For reference:

• LLDP is a standard link-layer neighbor discovery protocol (IEEE 802.1AB).
• PN-DCP is used by PROFINET to discover devices and retrieve basic information like device name, vendor ID, and IP configuration.

Questions:

1. Does n3n support forwarding or handling LLDP frames across the virtual network?
2. Does n3n support PN-DCP discovery packets (PROFINET DCP Identify)?
3. If not, would it be possible to support these Layer-2 discovery protocols in the future?
4. Are there recommended configurations or workarounds to allow these protocols to work over an n3n virtual network?

Use case:
We would like to connect industrial devices (e.g., Siemens PLCs) across remote networks via n3n while still allowing standard industrial discovery mechanisms to work.

Thanks for your work on this project!

[hamishcoleman]

It is an easy and supported option to disable the filtering of multicast packets and use multicast over n3n as this is required to support IPv6 on the tunnel network.

The default configuration filters most multicast (and broadcast) traffic to reduce the extra packets that can be flooded onto the VPN network.

Thus LLDP from edge to edge should also work fine.

Since I do not expect that your remote PLC hardware will not be able to run the edge software itself, you will need to enable the network bridging feature as well.

I have not personally tried this combination of multicast+LLDP and bridging, but if it doesnt work, that would be a bug that we should fix.

[983674707]

Hi,

Thanks for the explanation.

I tried the configuration you suggested:

1. Disabled multicast filtering
2. Enabled bridging
3. Created a Linux bridge and added both the physical NIC and the n3n edge interface to the bridge

Topology:

PLC ---- eth0
           |
          br0
         /   \
      edge   local host

However, LLDP and PROFINET DCP discovery still do not seem to work across the tunnel.

From the edge logs I can see messages like:

collect_packet_info stumbled across the unknown ether type 0x88CC
collect_packet_info stumbled across the unknown ether type 0x8892

From what I understand:

0x88CC → LLDP
0x8892 → PROFINET DCP

So it seems the packets are reaching the edge, but they are being treated as unknown Ethernet types and possibly filtered by network_traffic_filter.

This suggests LLDP and PN-DCP frames might not currently be forwarded across the tunnel.

Do these EtherTypes need to be explicitly allowed in the filter logic?

Thanks!

[hamishcoleman]

Those collect_packet_info messages are informational only - it is not direct evidence of any packets being filtered. There is no need to explicitly allow different ethertypes.

If you can capture packets from the two edges, it might show if some of the traffic is getting through. The pcap files, might also allow the situation to be replicated in a test environment