IP Backbone Design for Large KNX Installations: VLANs and QoS
For installations with more than 3 KNX TP lines, or where TP lines span multiple buildings or floors, an IP backbone connects KNXnet/IP routers via standard Ethernet — faster, longer range and more flexible than extending TP with additional line couplers. Getting the network design right means KNX telegrams arrive on time, every time.
When to use an IP backbone
The decision to use an IP backbone is driven by device count, building topology and geographic spread. A single TP line handles up to 64 devices — beyond that, you need either more TP lines connected by couplers, or an IP backbone connecting KNXnet/IP routers.
| Scenario | Recommended topology | IP backbone |
|---|---|---|
| Single building, < 64 devices | One TP line, one 640mA PSU | Not required |
| Single building, 64–640 devices | IP backbone with 2–10 KNX TP lines | Recommended |
| Single building, > 640 devices | IP backbone with 10+ lines | Required |
| Multi-floor commercial building | One KNXnet/IP router per floor, IP backbone on riser | Required |
| Multi-building campus | IP backbone via site fiber, one TP line per building zone | Mandatory |
| Remote building integration | KNXnet/IP over WAN with VPN, DSCP marking on WAN | Mandatory |
IP backbone architecture
The standard KNX IP backbone for a multi-floor commercial building uses a core managed switch at the MDF (Main Distribution Frame), with per-floor IDF (Intermediate Distribution Frame) switches connecting to each floor's KNXnet/IP router.
IP backbone topology — multi-floor commercial building
Core managed switch (MDF — basement or ground floor) Cisco SG350-28P / TP-Link SG3428X / Ubiquiti US-24 VLAN 10: KNX backbone (tagged on all trunk uplinks) IGMP snooping: enabled Multicast routing: 224.0.23.12 within VLAN 10 QoS: DSCP 46 → strict priority queue │ ├─── SFP/fiber uplink ──► Floor 1 IDF (Cat6A or OM3 fiber) │ MDT SCN-IP200.02 IP Router │ Physical address: 1.0.0 (Area 1) │ KNX TP Line — floor 1 devices │ ├─── SFP/fiber uplink ──► Floor 2 IDF │ MDT SCN-IP200.02 IP Router │ Physical address: 2.0.0 (Area 2) │ KNX TP Line — floor 2 devices │ ├─── SFP/fiber uplink ──► Floor 3 IDF │ [repeat for each floor] │ └─── [up to 15 areas on KNX IP backbone]
Each floor's KNXnet/IP router acts as an area coupler — its TP side connects the floor devices, its IP side sends and receives KNXnet/IP multicast on VLAN 10. ETS configures the group address filter table on each router to forward only the group addresses relevant to that floor.
VLAN for KNX
Isolating KNX traffic in a dedicated VLAN prevents multicast storms on general IT networks, separates KNX alarms from general network monitoring and provides a security boundary between the building automation and guest/corporate IT traffic.
VLAN configuration — Cisco SG350 example
! Create VLAN 10 for KNX backbone vlan 10 name KNX-Backbone ! Trunk port to floor IDF switch (tagged VLAN 10) interface GigabitEthernet1 description "Trunk to Floor 1 IDF" switchport mode trunk switchport trunk allowed vlan add 10 ! Access port for KNXnet/IP router on floor (untagged) interface GigabitEthernet5 description "MDT IP Router Floor 1" switchport mode access switchport access vlan 10 ! Enable IGMP snooping on VLAN 10 ip igmp snooping vlan 10 ip igmp snooping vlan 10 querier ! Multicast routing for 224.0.23.12 within VLAN 10 ip multicast-routing interface Vlan10 ip igmp version 2
Why VLAN isolation
- • KNX multicast 224.0.23.12 stays within KNX VLAN
- • Guest Wi-Fi devices cannot reach KNX routers
- • CCTV and AV traffic does not compete with KNX
- • Network monitoring per-system (KNX vs IT)
VLAN port configuration
- • Trunk ports: tagged VLAN 10 to IDF switches
- • Access ports: untagged VLAN 10 to IP routers
- • Never put IP routers on the default VLAN 1
- • Separate VLAN for engineering laptop access
Management access
- • KNX VLAN 10: IP routers only
- • Management VLAN (e.g. VLAN 99): switch access
- • Engineering laptop: routed access to VLAN 10 via VPN
- • Firewall rules between VLANs — allow only port 3671
QoS: Quality of Service for KNX
KNX telegrams are tiny — maximum 23 bytes — but they are time-sensitive. The KNX TP collision detection mechanism depends on precise telegram timing. If IP network congestion delays a telegram by even 10–20ms, the TP side may misinterpret it as a collision and retransmit, causing visible delays and event duplication.
QoS DSCP marking — Cisco SG350 / TP-Link SG3428X
! Mark KNX multicast traffic with DSCP 46 (Expedited Forwarding) ! Apply on the access port connected to each KNXnet/IP router interface GigabitEthernet5 description "MDT IP Router Floor 1" mls qos trust dscp ! Trust DSCP set by KNX router ! If KNX router does not set DSCP, mark it at ingress: ! (MDT SCN-IP200.02 sets DSCP 46 by default — verify in ETS) ! QoS policy — strict priority for DSCP 46 mls qos class-map match-all KNX-TRAFFIC match ip dscp 46 ! EF — Expedited Forwarding policy-map KNX-PRIORITY class KNX-TRAFFIC priority ! Strict priority queue class class-default fair-queue ! Best-effort for everything else ! Apply on uplink to core interface GigabitEthernet1 service-policy output KNX-PRIORITY
DSCP value selection
- DSCP 46 (EF — Expedited Forwarding): highest priority, real-time class. Recommended for KNX — same class as VoIP.
- DSCP 34 (AF41): acceptable alternative — assured forwarding, lower priority than EF. Use on networks shared with VoIP where EF is reserved.
- DSCP 0 (Best Effort): never use for KNX backbone — no priority guarantees.
Why QoS matters for KNX
- • 4K video streams: 20–50 Mbit/s — can saturate a 100Mbit link briefly
- • KNX telegram: 23 bytes = 0.18 kbit — negligible bandwidth but time-sensitive
- • Without QoS: video burst delays KNX = lights respond 200ms late
- • With DSCP 46 strict priority: KNX telegrams queue-jump every time
Multicast configuration
KNXnet/IP routing uses the IANA-registered multicast address 224.0.23.12. Without proper multicast configuration on the switches, this traffic floods to all ports on the VLAN — causing unnecessary load on every device and potential timing issues.
IGMP snooping — enable on all switches (Cisco / HP / Ubiquiti)
# Cisco SG350 (CLI): ip igmp snooping ! Enable globally ip igmp snooping vlan 10 ! Enable on KNX VLAN ip igmp snooping vlan 10 querier ! IGMP querier (one per VLAN) # HP/Aruba ProCurve (CLI): ip igmp ! Enable globally vlan 10 igmp ! Enable on KNX VLAN # Ubiquiti UniFi (GUI): Network → Settings → Networks → KNX-Backbone Enable IGMP Snooping: ON Multicast DNS: OFF (not needed for KNX) # TP-Link SG3428X (CLI): ip igmp-snooping enable ip igmp-snooping vlan 10 enable ip igmp-snooping vlan 10 querier-election enable
Configure exactly one IGMP querier per VLAN. If no querier is present, switches may flush their multicast group membership tables and multicast will flood again. The core managed switch is the natural place for the querier. Check with: show ip igmp snooping groups vlan 10 — you should see 224.0.23.12 listed.
Cable infrastructure
The IP backbone cabling must be specified at the same time as the KNX TP cabling — ideally in the same cable design document. KNX backbone failures are almost always copper cable failures (bent SFP, wrong fiber type, wrong connector standard).
Copper — in-building
- • Cat6A (10GbE rated) for backbone riser
- • Cat6 minimum for floor switch to router
- • Shielded (F/UTP or S/FTP) in plant rooms
- • Max 100m per copper segment
- • Patch panel at each floor IDF
Fiber — between buildings
- • OM3 multimode SFP: up to 300m (10GbE)
- • OM4 multimode SFP: up to 400m (10GbE)
- • OS2 singlemode SFP: 10km+ (for remote sites)
- • LC/LC duplex connectors standard
- • Steel-armored conduit for outdoor runs
Panel infrastructure
- • Cat6A keystone patch panel per floor IDF
- • SFP-based fiber uplinks to core switch
- • Label all ports with VLAN ID and device
- • Cable management: 1U for every 24 ports
- • PDU with surge protection at each IDF
Managed switch recommendation
Never use unmanaged switches on the KNX backbone. Without multicast control, 224.0.23.12 floods to all ports and every device on the switch receives every KNX telegram — causing CPU load, timing issues and making troubleshooting impossible.
| Switch | Ports | IGMP snooping | VLAN | DSCP QoS | PoE |
|---|---|---|---|---|---|
| Cisco SG350-28P | 24× GbE + 4× SFP | Yes | Yes (802.1Q) | Yes (DSCP/CoS) | Yes (PoE+) |
| TP-Link TL-SG3428X | 24× GbE + 4× SFP+ | Yes | Yes (802.1Q) | Yes (DSCP/CoS) | No |
| Ubiquiti US-24 | 24× GbE + 2× SFP | Yes | Yes (802.1Q) | Yes (DSCP) | Optional |
| Netgear GS324T | 24× GbE + 2× SFP | Yes | Yes (802.1Q) | Yes (DSCP) | No |
| Unmanaged switch | Variable | No | No | No | Optional |
Worked example: 8-floor office building
A typical 8-floor commercial office — one KNX TP line per floor, 50–60 devices per line, total approximately 450 KNX devices. This is the most common scenario where an IP backbone is the right answer.
8-floor office — network design summary
Equipment:
Core switch: Cisco SG350-28P (basement MDF)
Floor switches: 8× Cisco SG350-10P (one per floor IDF)
KNX routers: 8× MDT SCN-IP200.02 (one per floor)
Cabling: OM3 multimode fiber — basement to each floor IDF
Cat6A copper — floor IDF to KNX IP router (PoE+)
VLAN layout:
VLAN 1 — default (unused — no devices)
VLAN 10 — KNX backbone (all KNX IP routers)
VLAN 20 — building IT (PCs, printers)
VLAN 30 — CCTV/IP cameras
VLAN 99 — management (switch management interfaces)
KNX physical address assignment:
Floor 1: MDT IP Router → PA 1.0.0 (Area 1)
Floor 2: MDT IP Router → PA 2.0.0 (Area 2)
Floor 3: MDT IP Router → PA 3.0.0 (Area 3)
...
Floor 8: MDT IP Router → PA 8.0.0 (Area 8)
QoS policy (all switches):
DSCP 46 (Expedited Forwarding) → Strict priority queue
Source: MDT SCN-IP200.02 marks KNX telegrams DSCP 46 by default
IGMP multicast group (VLAN 10):
Group: 224.0.23.12
Members: all 8 MDT IP routers (one per floor)
Querier: Cisco SG350-28P core switchVerify multicast group table — Cisco SG350
# Show IGMP snooping group membership for VLAN 10
show ip igmp snooping groups vlan 10
Expected output:
VLAN Group Type Version Port List
---- ----- ---- ------- ---------
10 224.0.23.12 dynamic IGMPv2 Gi1, Gi2, Gi3, Gi4,
Gi5, Gi6, Gi7, Gi8
# 8 ports = 8 floor switches, each with one MDT IP router
# If a floor is missing: check the IP router is powered and
# the TP line has valid KNX traffic (IGMP join requires activity)KNX network infrastructure in your panel
We design panels with pre-configured KNXnet/IP routers, IP backbone patch bays and structured cabling termination — tested end-to-end before leaving the factory.
Request a quote →