KNXnet/IP: when to route and when to tunnel

KNXnet/IP is the standard that lets KNX traffic ride on top of IP networks. It comes in two flavours and they solve different problems.

Tunneling is point-to-point. A client (typically ETS6 or a visualization server) opens a unicast connection to a KNXnet/IP interface on a specific line. The interface forwards bus traffic to the client, the client sends telegrams back. Most KNX-IP interfaces support 4 simultaneous tunneling connections; some support 8. Use tunneling for ETS commissioning over a VPN, for a visualization PC, or for a small smart-home gateway.

Routing is multicast. A KNXnet/IP router on every line listens to multicast group 224.0.23.12 and forwards eligible telegrams between the IP backbone and its local TP line. This builds a multi-line KNX backbone that runs over IP infrastructure rather than dedicated TP backbone cabling. Use routing for new backbones, for retrofits where pulling new TP cable is impractical, and for distributed sites connected over a building LAN.

A common mistake is to use tunneling where routing was intended. If you want telegrams from line 1.2 to reach actuators on line 1.3, you need routers on both lines, not tunneling interfaces. Tunneling only makes the traffic visible to the connected client.

Network hygiene matters. KNX multicast traffic can be heavy on a poorly configured switch. Enable IGMP snooping on the building LAN switches so multicast packets only reach ports that subscribed to the group. Without IGMP snooping, every KNX telegram floods every switch port, which causes problems on networks shared with VoIP or video.

Finally, do not expose KNX-IP routers to the public internet. Always sit them behind a VPN or KNX IP Secure when remote access is needed.