KNX IP is widely used for connecting KNX TP lines, areas and higher-level systems over Ethernet networks. At the centre of KNXnet/IP Routing is IP multicast, which allows KNX IP Routers to exchange KNX telegrams over the IP network.
For an integrator, understanding multicast is important because a KNX IP network can appear completely healthy at the basic IP level while KNX routing still fails. Ping may work, devices may have valid IP addresses, and ETS may discover some devices—yet telegrams may not pass between KNX lines.
This guide explains how KNX IP multicast works, what the network infrastructure must support, and how to troubleshoot routing problems in practical installations.
1. KNX IP Multicast and KNXnet/IP Routing Explained
KNXnet/IP Routing is the mechanism used by KNX IP Routers to exchange KNX telegrams between different KNX lines or areas through an Ethernet/IP network. Unlike a conventional point-to-point connection, routing uses IP multicast, allowing multiple KNX IP Routers on the same IP network to receive the relevant KNX routing traffic.
The default KNX routing multicast address is 224.0.23.12, and the standard KNXnet/IP port is 3671. The routing multicast address can also be configured differently, for example when separate KNX installations need to coexist on the same IP/LAN infrastructure.
Basic KNX IP routing architecture
KNX TP Line 1
│
┌─────────────┐
│ KNX IP │
│ Router 1 │
└──────┬──────┘
│
│ Ethernet
│
┌──────▼──────┐
│ Network │
│ Switch │
└──┬────────┬─┘
│ │
Multicast Multicast
│ │
┌───────▼───┐ ┌──▼────────┐
│ KNX IP │ │ KNX IP │
│ Router 2 │ │ Router 3 │
└───────┬───┘ └────┬──────┘
│ │
KNX TP Line 2 KNX TP Line 3When Router 1 sends a routing telegram onto the IP network, the multicast mechanism allows other KNX IP Routers listening to the same multicast group to receive it.
Routing vs tunnelling
These two functions are often confused.
| Feature | KNXnet/IP Routing | KNXnet/IP Tunnelling |
|---|---|---|
| Primary purpose | Connect KNX lines/areas | Connect an individual client to KNX |
| Communication model | Multicast | Point-to-point connection |
| Typical device | KNX IP Router | KNX IP Interface |
| Used for | KNX backbone/distributed topology | ETS, visualization, programming |
| Multicast required | Yes | No |
| Typical port | 3671 | 3671 |
KNX Association documentation distinguishes routing from tunnelling: tunnelling provides a connection between a client such as ETS and a KNX interface, while routing is used with IP routers for KNXnet/IP routing.
Important integrator point
A successful ping does not prove that KNX IP Routing is working.
Ping tests ordinary IP reachability. KNX routing additionally depends on correct multicast handling, matching multicast configuration and suitable network infrastructure.
2. KNX IP Multicast Network Requirements
The IP network becomes part of the KNX backbone when KNX IP Routers are used for KNXnet/IP Routing. Therefore, the Ethernet infrastructure must be designed to handle the multicast traffic correctly.
The most important parameters are the multicast address, IP network arrangement, switch behaviour, VLAN configuration and security policies. KNX Association specifically notes that network infrastructure such as smart switches and Wi-Fi access points can block discovery frames and recommends checking multicast forwarding and IGMP configuration when this occurs.
Default KNX multicast parameters
| Parameter | Typical value |
|---|---|
| KNX routing multicast address | 224.0.23.12 |
| KNXnet/IP port | 3671 |
| Transport | IP/UDP-based KNXnet/IP communication |
| Main purpose | KNXnet/IP Routing |
| Configuration | Defined by the KNX IP line in ETS |
The default multicast address is documented by KNX Association as 224.0.23.12. ETS can obtain the routing multicast address from the IP line configuration, reducing the possibility of inconsistent device-level settings.
Switch configuration
A managed switch should be evaluated carefully when KNX IP Routing is used.
Important areas include:
- IGMP Snooping
- Multicast forwarding
- VLAN configuration
- Multicast filtering
- Port isolation
- Broadcast/multicast storm protection
- Firewall or ACL rules
- Network segmentation
A switch can allow normal unicast traffic while treating multicast traffic differently.
This creates one of the classic KNX IP troubleshooting situations:
PC ───────────────► KNX IP Router
PING ✓
PC ───────────────► KNX IP Router
KNX discovery ✓/✗
KNX IP Router A ──► KNX IP Router B
Routing ✗The physical Ethernet connection may therefore be healthy while multicast communication is not.
IGMP Snooping
IGMP Snooping is particularly relevant on managed switches because it controls how multicast traffic is distributed within the switching infrastructure.
An incorrectly configured multicast environment can result in KNX IP Routers not receiving the multicast traffic they require.
This does not mean that IGMP should simply be disabled on every KNX network. The correct configuration depends on the switch architecture, VLAN design and multicast behaviour of the network.
VLAN considerations
If KNX IP Routers are distributed across different VLANs, the network design must explicitly support the required multicast communication between those network segments.
Do not assume that ordinary IP routing between VLANs automatically means that KNX multicast will also work.
For larger commercial projects, KNX IP network design should therefore be coordinated with the network administrator rather than treating the KNX IP Routers as ordinary Ethernet endpoints.
Security and firewall considerations
Firewalls, VPNs, access-control policies and other security mechanisms can affect KNX IP communication.
KNX Association specifically identifies firewalls, VPNs and network security policies as factors that can affect KNX IP communication.
For a production installation:
- Do not expose KNXnet/IP directly to the public Internet.
- Restrict access to the KNX network.
- Coordinate required ports and multicast behaviour with the IT team.
- Document VLANs and IP addressing.
- Use appropriate secure remote-access architecture when remote access is required.
3. KNX IP Multicast Troubleshooting
KNX IP multicast problems can be difficult to diagnose because many conventional network tests may appear normal.
A router can have a valid IP address, respond to ping and even appear in ETS, while KNX telegrams still fail to cross from one KNX line to another. The troubleshooting process should therefore move from basic IP connectivity toward multicast-specific testing.
Typical symptoms
Common symptoms include:
- KNX IP Router is offline in ETS.
- IP Router cannot be discovered.
- IP Router appears and disappears.
- Programming works intermittently.
- One KNX line cannot communicate with another.
- Telegrams appear on one line but not another.
- Multiple IP Routers are visible but routing does not work.
- Routing stops after a switch or VLAN change.
- KNX communication works when directly connected but fails through the building network.
KNX Association identifies network infrastructure, smart switches, Wi-Fi access points and security software as possible causes when IP interfaces are not discovered.
Practical troubleshooting sequence
Step 1 — Check the KNX IP Router
Verify:
- Device is powered.
- Ethernet link is active.
- IP address is correct.
- Subnet configuration is correct.
- Device is in the correct ETS IP line.
- Individual address is appropriate for its topology.
- Routing multicast address is correct.
The routing multicast address is normally defined by the IP line in ETS.
Step 2 — Test basic IP connectivity
From a commissioning laptop:
Laptop
│
├── Ping Router A
│ ✓
│
├── Ping Router B
│ ✓
│
└── Check IP configurationIf basic IP communication fails, solve that first.
But remember:
Ping success ≠ KNX multicast success.
Step 3 — Check multicast configuration
Verify that:
- Routers use the same intended multicast address.
- The switch permits the multicast traffic.
- VLAN configuration is correct.
- IGMP behaviour is appropriate.
- ACL/firewall rules are not blocking the traffic.
KNX Association specifically recommends checking IP multicast forwarding and IGMP when network infrastructure blocks KNX discovery traffic.
Step 4 — Check ETS communication
Use ETS diagnostics and the Group Monitor to determine whether telegrams are being generated and received.
For example:
KNX TP Line 1
│
│ Telegram generated
▼
IP Router 1
│
│ Multicast
▼
Ethernet Network
│
▼
IP Router 2
│
▼
KNX TP Line 2If the telegram appears on Line 1 but not Line 2, the problem may be in the IP routing path rather than the original KNX device.
Troubleshooting matrix
| Symptom | Possible area to investigate |
|---|---|
| Router not discovered | PC firewall, switch, multicast |
| Ping fails | IP/VLAN/cabling |
| Ping works but routing fails | Multicast configuration |
| One VLAN works, another fails | VLAN/multicast routing |
| Routing intermittent | IGMP/switch behaviour |
| ETS connects but telegrams don’t cross lines | Routing configuration/network |
| Multiple routers interfere | Multicast architecture |
| Works on direct switch, fails on building LAN | Managed network policies |
The objective is to identify where the telegram stops, rather than repeatedly downloading the KNX project or replacing devices.
4. KNX IP Multicast Design and Commissioning Checklist
A reliable KNX IP installation starts with network planning rather than troubleshooting after commissioning. The KNX IP Routers, Ethernet switches, VLANs, multicast configuration and security policies should be considered as one communication infrastructure.
For commercial buildings especially, the KNX integrator and IT/networking team should agree on the IP architecture before commissioning begins.
KNX IP multicast design checklist
KNX configuration
- KNX IP Router selected according to topology.
- Individual addresses correctly assigned.
- IP lines correctly configured in ETS.
- Routing multicast address documented.
- IP Router parameters checked.
- Filter tables correctly configured.
- Backbone/area topology verified.
Network configuration
- IP addressing documented.
- VLAN assignment documented.
- Required multicast traffic permitted.
- IGMP configuration verified.
- Multicast filtering checked.
- ACL/firewall rules reviewed.
- Switch configuration documented.
Commissioning
- Each KNX IP Router reachable.
- ETS can discover/connect to required devices.
- KNX telegrams verified on each TP line.
- Cross-line telegrams tested.
- Group Monitor checked.
- Fault conditions tested where practical.
- Network changes documented after commissioning.
Recommended architecture
For a typical commercial KNX installation:
KNX IP Backbone
│
┌──────────┴──────────┐
│ Managed Ethernet │
│ Switch │
└─────┬─────┬────────┘
│ │
┌─────┘ └─────┐
▼ ▼
KNX IP Router KNX IP Router
│ │
KNX TP Line 1 KNX TP Line 2
│ │
Sensors/Actuators Sensors/ActuatorsFor larger systems, document the KNX topology and IP topology together. This makes future troubleshooting considerably easier because an engineer can immediately identify which IP Router connects to which KNX line and which network segment carries the routing traffic.
Final integrator checklist
Before handing over a KNX IP installation, verify:
KNX → IP Router → Switch → Multicast → IP Router → KNX
Every stage should be tested.
The most important principle is:
A working IP connection does not automatically mean a working KNX IP routing network.
KNX IP Routing depends on correct multicast configuration and suitable network infrastructure. The default KNX routing multicast address is 224.0.23.12, while KNXnet/IP uses port 3671 by default.
For projects using managed enterprise networks, the KNX integrator should work together with the IT/networking team to verify multicast, VLAN, switch and security behaviour before commissioning.
