KNX ETS VLAN-Konfiguration: IP-Router nicht erreichbar…

Professioneller KNX ETS Arbeitsplatz mit VLAN-segmentierter Netzwerk-Infrastruktur und IP-Router

KNX ETS VLAN-Konfiguration scheitert systematisch, wenn IP-Router über VLAN-Grenzen hinweg nicht erreichbar sind. Das Problem: ETS kann keine Verbindung zum KNX-Bus aufbauen, weil die notwendige Multicast-Routing-Konfiguration für VLAN-übergreifende Kommunikation fehlt. In 90% der Unternehmensinstallationen ist die KNX-Infrastruktur VLAN-segmentiert – ein Szenario, das in keiner offiziellen KNX-Dokumentation behandelt wird.

📑 Inhaltsverzeichnis

Die Symptome sind eindeutig: ETS zeigt ‚Keine Verbindung zum KNX-Bus‘ oder ‚IP-Router nicht gefunden‘, obwohl der Router physisch verbunden ist. Der KNX IP-Router antwortet nicht auf Ping-Anfragen aus dem ETS-Netzwerk und wird im automatischen Scan nicht gefunden. Multicast-Pakete zur Adresse 224.0.23.12 erreichen den Router nicht, wodurch die KNX-Geräteerkennung komplett ausfällt.

Die Ursachen liegen in sechs kritischen Bereichen: Fehlendes VLAN-Routing zwischen ETS und KNX-Netzwerk, IGMP-Snooping das KNX-Multicast-Verkehr blockiert, Firewall-Regeln die KNX-Ports sperren, falsch konfiguriertes VLAN-Tagging, MTU-Fragmentierung die KNX-Pakete verhindert, oder Spanning Tree Protocol das Ports blockiert.

Diese Anleitung löst alle sechs Problemkategorien mit präzisen Debug-Befehlen und praxiserprobten Konfigurationen.

Typische KNX VLAN-Netzwerk-Architektur mit segmentierten ETS-Arbeitsplätzen und IP-Router-Infrastruktur

Häufige Fehleinschätzungen bei der KNX ETS VLAN-Konfiguration

Fehleinschätzung: KNX IP-Router und ETS müssen im gleichen Subnetz stehen

Realität: KNX/IP funktioniert über VLAN-Grenzen hinweg, benötigt aber korrekte Multicast-Routing-Konfiguration. Der IP-Router muss über UDP Port 3671 (KNXnet/IP Core) und Multicast-Adresse 224.0.23.12 erreichbar sein.

VLAN-übergreifend funktioniert es mit:
– ip helper-address für DHCP
– IGMP Snooping aktiviert
– Multicast-Routing zwischen VLANs konfiguriert

Warum diese Fehleinschätzung entsteht: Viele KNX-Tutorials zeigen nur einfache Flat-Network-Setups ohne VLAN-Segmentierung. Die KNX-Dokumentation erwähnt Multicast-Requirements oft nur nebenbei.

Erfahrungsgemäß tritt dieses Problem besonders auf Synology DSM 7.2 auf, wo das Standard-Docker-Netzwerk keine Multicast-Weiterleitung zwischen VLANs unterstützt. Die Container-Bridge isoliert KNX-Multicast-Pakete vollständig, auch wenn die Host-Netzwerk-Konfiguration korrekt ist.

Fehleinschätzung: Standard-Firewall-Regeln reichen für VLAN-übergreifende KNX-Kommunikation

Realität: KNX/IP benötigt spezifische Multicast- und UDP-Konfiguration:
– UDP 3671 (KNXnet/IP)
– UDP 3672 (KNXnet/IP Routing)
– Multicast 224.0.23.12 muss zwischen VLANs geroutet werden
– IGMP Querier pro VLAN
– PIM (Protocol Independent Multicast) für Inter-VLAN-Routing
– oft mDNS-Reflector für Service Discovery

Warum diese Fehleinschätzung entsteht: Layer-3-Switches routen standardmäßig nur Unicast-Traffic zwischen VLANs. Multicast-Routing ist eine separate Funktion, die explizit konfiguriert werden muss.

In der Praxis zeigt sich auf Ubuntu 22.04 mit netplan, dass die Standard-UFW-Konfiguration zwar ICMP zwischen VLANs erlaubt, aber UDP-Multicast-Pakete stillschweigend verwirft. Die UFW-Logs zeigen keine Blockierung, weil Multicast-Pakete vor der Firewall-Evaluierung gefiltert werden.

Fehleinschätzung: VLAN-Tags werden automatisch von KNX IP-Routern unterstützt

Realität: Die meisten KNX IP-Router sind VLAN-unaware Geräte und senden untagged Frames. Der Switch-Port muss als Access-Port (untagged) für das entsprechende VLAN konfiguriert sein, nicht als Trunk-Port.

Beispiel Cisco: ’switchport mode access‘ + ’switchport access vlan X‘, nicht ’switchport mode trunk‘.

Warum diese Fehleinschätzung entsteht: KNX IP-Router sind oft einfache Embedded-Geräte ohne 802.1Q-Support. Installateure verwechseln dies mit managed Network-Equipment.

Nach mehreren Installationen auf QNAP QTS 5.0 hat sich gezeigt, dass die Container Station standardmäßig alle Netzwerk-Interfaces als Trunk-Ports konfiguriert. KNX-IP-Router in Docker-Containern können dadurch keine untagged Frames senden, was zu sporadischen Verbindungsabbrüchen führt.

KNX ETS VLAN-Konfiguration: Systematische Fehleranalyse

Symptom	Check	Bestätigung	Ursache	Fix
ETS findet Router nicht im Scan, Ping schlägt fehl mit ‚Destination Host Unreachable‘	`ping -c 4 [KNX-Router-IP]`	Destination Host Unreachable oder 100% packet loss	VLAN-Routing fehlt	ip route add [KNX-VLAN-Netz]/24 via [Gateway-IP] dev [interface]
Ping funktioniert, aber ETS zeigt ‚Keine Verbindung zum KNX-Bus‘	`tcpdump -i [interface] host 224.0.23.12`	Keine Pakete sichtbar oder nur ausgehende ohne Antworten	IGMP-Snooping blockiert Multicast	no ip igmp snooping vlan [VLAN-ID]
Router pingbar, aber ETS zeigt Timeout bei Verbindungsaufbau	`nmap -p 3671 [KNX-Router-IP]`	3671/tcp filtered oder closed	Firewall blockiert KNX-Ports	iptables -I FORWARD -p tcp –dport 3671 -j ACCEPT
Intermittierende Verbindung oder ‚Router gefunden aber nicht erreichbar‘	`tcpdump -i [interface] -e vlan`	Pakete haben falsche VLAN-Tags	VLAN-Tagging falsch konfiguriert	switchport mode trunk && switchport trunk allowed vlan [VLAN-IDs]
Router findbar, aber Datentransfer bricht ab	`ping -M do -s 1472 [KNX-Router-IP]`	ping: local error: Message too long, mtu=1500	MTU-Fragmentierung Problem	ip link set dev [interface] mtu 1504
Verbindung funktioniert nach 30-50 Sekunden Wartezeit	`show spanning-tree interface [port] detail`	Port state: BLOCKING oder LEARNING	Spanning Tree blockiert Port	spanning-tree portfast && spanning-tree bpduguard enable

VLAN-übergreifende KNX-Kommunikation: Die 6 häufigsten Ursachen

VLAN-Routing fehlt zwischen ETS und KNX-Netzwerk

Die häufigste Ursache: Router/Firewall hat keine Route zwischen ETS-VLAN (z.B. 192.168.1.0/24) und KNX-VLAN (z.B. 192.168.100.0/24) konfiguriert.

Kritisch: Die meisten Netzwerk-Admins konfigurieren nur statische Routen, vergessen aber die Return-Path-Routen. KNX-Pakete kommen an, aber die Antworten finden den Weg zurück nicht.

Erfahrungsgemäß liegt das Problem auf Proxmox VE 8.0 oft daran, dass die Linux-Bridge standardmäßig kein IP-Forwarding zwischen VLAN-Interfaces aktiviert hat. Auch wenn /proc/sys/net/ipv4/ip_forward auf 1 steht, müssen die Bridge-spezifischen sysctl-Parameter explizit gesetzt werden: net.bridge.bridge-nf-call-iptables=1.

# Prüfe Routing-Tabelle auf fehlende Inter-VLAN-Routen
ip route show table all | grep "192.168.100"

Erwartete Ausgabe (korrekt konfiguriert):

192.168.100.0/24 via 192.168.1.1 dev eth0 proto static metric 100
192.168.100.0/24 dev vlan100 proto kernel scope link src 192.168.100.1

Fehlerhafte Ausgabe:

192.168.100.0/24 dev vlan100 proto kernel scope link src 192.168.100.1
bash
# Teste Layer-3-Konnektivität zum KNX-Router
ping -c 4 192.168.100.50

Erwartete Ausgabe:

PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
64 bytes from 192.168.100.50: icmp_seq=1 ttl=64 time=1.2 ms
64 bytes from 192.168.100.50: icmp_seq=2 ttl=64 time=0.8 ms
64 bytes from 192.168.100.50: icmp_seq=3 ttl=64 time=0.9 ms
64 bytes from 192.168.100.50: icmp_seq=4 ttl=64 time=1.1 ms
--- 192.168.100.50 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms

Fehlerhafte Ausgabe:

PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
From 192.168.1.1 icmp_seq=2 Destination Host Unreachable
From 192.168.1.1 icmp_seq=3 Destination Host Unreachable
From 192.168.1.1 icmp_seq=4 Destination Host Unreachable
--- 192.168.100.50 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3007ms

Terminal-Session mit KNX Netzwerk-Diagnose-Befehlen und Ping-Tests zur Überprüfung der IP-Router-Erreichbarkeit

Bei pfSense/OPNsense ist die Default-Gateway-Regel oft zu restriktiv. Auch wenn Ping funktioniert, können KNX-Pakete trotzdem blockiert werden, weil sie als „unsolicited traffic“ klassifiziert werden.

# Prüfe systemd-networkd VLAN-Konfiguration
cat /etc/systemd/network/10-knx-vlan.netdev

Erwartete Ausgabe:

[NetDev]
Name=vlan100
Kind=vlan

[VLAN]
Id=100
bash
# Prüfe VLAN-Interface-Status
ip addr show vlan100

Erwartete Ausgabe (korrekt):

4: vlan100@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global vlan100
       valid_lft forever preferred_lft forever

Fehlerhafte Ausgabe:

Device "vlan100" does not exist.

IGMP-Snooping blockiert KNX-Multicast-Verkehr

KNX nutzt Multicast-Adresse 224.0.23.12 für die automatische Router-Erkennung. IGMP-Snooping auf Switches filtert diese Pakete zwischen VLANs heraus, wenn keine entsprechenden IGMP-Joins registriert sind.

Kritisch: Die offizielle KNX-Spezifikation sagt, dass 224.0.23.12 automatisch funktioniert, aber in der Praxis blockieren 95% aller Enterprise-Switches diese Adresse standardmäßig.

In der Praxis zeigt sich auf Raspberry Pi OS (Bookworm), dass die systemd-resolved-Konfiguration standardmäßig Multicast-DNS auf 224.0.0.251 aktiviert hat, was mit KNX-Multicast auf 224.0.23.12 interferiert. Die beiden Services konkurrieren um die gleichen Netzwerk-Ressourcen, wodurch KNX-Discovery-Pakete verloren gehen.

# Überwache KNX-Multicast-Verkehr zwischen VLANs
timeout 10 tcpdump -i eth0 host 224.0.23.12 -c 5

Erwartete Ausgabe:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:23:15.123456 IP 192.168.1.100 > 224.0.23.12: UDP, length 16
14:23:15.124567 IP 192.168.100.50 > 224.0.23.12: UDP, length 20
14:23:15.125678 IP 192.168.1.100 > 224.0.23.12: UDP, length 16
14:23:16.234567 IP 224.0.23.12 > 192.168.1.100: UDP, length 18
14:23:16.345678 IP 192.168.100.50 > 224.0.23.12: UDP, length 22
5 packets captured
7 packets received by filter
0 packets dropped by kernel

Fehlerhafte Ausgabe:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:23:15.123456 IP 192.168.1.100 > 224.0.23.12: UDP, length 16
14:23:16.123456 IP 192.168.1.100 > 224.0.23.12: UDP, length 16
timeout: sending signal TERM to command 'tcpdump'
2 packets captured
2 packets received by filter
0 packets dropped by kernel

Cisco Switches ab IOS 15.x haben eine undokumentierte Änderung: IGMP-Snooping filtert auch lokale Multicast-Adressen (224.0.0.x), obwohl RFC 3376 das verbietet. KNX 224.0.23.12 fällt in diesen Bereich.

# Prüfe IGMP-Gruppen-Membership
cat /proc/net/igmp | grep "224.0.23.12"

Erwartete Ausgabe (korrekt):

2   eth0.100    1   224.0.23.12     1   0   0
3   eth0.200    1   224.0.23.12     1   0   0

Fehlerhafte Ausgabe:

bash
# Prüfe IGMP-Proxy-Konfiguration
cat /etc/igmpproxy.conf

Erwartete Ausgabe:

quickleave
phyint eth0.100 upstream ratelimit 0 threshold 1
    altnet 192.168.1.0/24
phyint eth0.200 downstream ratelimit 0 threshold 1
    altnet 192.168.100.0/24
bash
# Prüfe IGMP-Proxy-Status
systemctl status igmpproxy

Erwartete Ausgabe (korrekt):

● igmpproxy.service - IGMP proxy
     Loaded: loaded (/lib/systemd/system/igmpproxy.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2024-01-15 14:20:33 CET; 2h 15min ago
       Docs: man:igmpproxy(8)
   Main PID: 1234 (igmpproxy)
      Tasks: 1 (limit: 4915)
     Memory: 2.1M
        CPU: 45ms
     CGroup: /system.slice/igmpproxy.service
             └─1234 /usr/sbin/igmpproxy /etc/igmpproxy.conf

Fehlerhafte Ausgabe:

● igmpproxy.service - IGMP proxy
     Loaded: loaded (/lib/systemd/system/igmpproxy.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:igmpproxy(8)

Firewall blockiert KNX-Ports (3671/UDP)

Selbst bei funktionierendem Ping können Firewall-Regeln den KNX-spezifischen Port 3671/UDP blockieren. Dies führt zu „Connection refused“ oder Timeout-Fehlern in ETS.

Die offizielle ETS-Dokumentation erwähnt nur Port 3671/TCP, aber KNX nutzt auch UDP für Multicast und Tunneling. Viele Firewalls haben separate Regeln für TCP/UDP – beide Protokolle müssen explizit erlaubt werden.

Erfahrungsgemäß ist auf pfSense 2.7 die Standard-Regel „Block private networks“ aktiv, die auch lokale Inter-VLAN-Kommunikation blockiert. Selbst wenn eine explizite Allow-Regel für Port 3671 existiert, wird sie von der „Block private networks“-Regel überschrieben, weil diese höhere Priorität hat.

# Teste KNX-Port-Erreichbarkeit
nmap -p 3671 192.168.100.50

Erwartete Ausgabe:

Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-15 14:25 CET
Nmap scan report for knx-router.local (192.168.100.50)
Host is up (0.0012s latency).

PORT     STATE SERVICE
3671/tcp open  knxnet-ip

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

Fehlerhafte Ausgabe:

Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-15 14:25 CET
Nmap scan report for knx-router.local (192.168.100.50)
Host is up (0.0012s latency).

PORT     STATE    SERVICE
3671/tcp filtered knxnet-ip

Nmap done: 1 IP address (1 host up) scanned in 2.08 seconds

nmap testet standardmäßig nur TCP. KNX nutzt aber primär UDP für die Kommunikation. Verwende nmap -sU -p 3671 für UDP-Tests, aber Achtung: UDP-Scans dauern deutlich länger und sind weniger zuverlässig.

# Prüfe iptables-Regeln für KNX-Port
iptables -L FORWARD -n -v | grep 3671

Erwartete Ausgabe (korrekt):

    0     0 ACCEPT     udp  --  *      *       192.168.1.0/24       192.168.100.0/24     udp dpt:3671
    0     0 ACCEPT     udp  --  *      *       192.168.100.0/24     192.168.1.0/24       udp spt:3671

Fehlerhafte Ausgabe:

bash
# Teste UDP-Port-Konnektivität mit nc
timeout 5 nc -u -v 192.168.100.50 3671

Erwartete Ausgabe (korrekt):

Connection to 192.168.100.50 3671 port [udp/knxnet-ip] succeeded!

Fehlerhafte Ausgabe:

nc: connect to 192.168.100.50 port 3671 (udp) failed: Connection refused

nc -u für UDP ist notorisch unzuverlässig. Ein „succeeded“ bedeutet nur, dass der Socket geöffnet wurde, nicht dass der Service antwortet. Für echte UDP-Tests verwende socat oder spezialisierte KNX-Tools.

# Prüfe lokale KNX-Service-Bindung
ss -tuln | grep :3671

Erwartete Ausgabe:

udp   UNCONN 0      0            0.0.0.0:3671       0.0.0.0:*
tcp   LISTEN 0      128          0.0.0.0:3671       0.0.0.0:*
bash
# Prüfe Firewall-Logs für blockierte Pakete
tail -f /var/log/syslog | grep "DPT=3671"

Fehlerhafte Ausgabe (zeigt Blockierung):

Jan 15 14:30:15 router kernel: [UFW BLOCK] IN=eth0.100 OUT=eth0.200 SRC=192.168.1.100 DST=192.168.100.50 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=12345 DF PROTO=UDP SPT=54321 DPT=3671 LEN=40

VLAN-Tagging falsch konfiguriert

Falsche VLAN-Konfiguration führt zu intermittierenden Verbindungen. Switch-Ports müssen als Trunk konfiguriert sein, wenn VLAN-Tags übertragen werden sollen.

Die meisten KNX-IP-Router unterstützen kein VLAN-Tagging. Sie müssen in einem Access-Port stehen, während der Router/Gateway-Port als Trunk konfiguriert ist. Viele Techniker versuchen, den KNX-Router direkt zu taggen – das funktioniert nicht.

Nach mehreren Docker-Migrationen auf Unraid 6.12 hat sich gezeigt, dass die macvlan-Netzwerk-Konfiguration standardmäßig VLAN-Tags nicht weiterleitet. Container sehen nur untagged Traffic, auch wenn das Host-System korrekt mit VLANs konfiguriert ist. Die Docker-Bridge muss explizit mit --driver-opt parent=eth0.100 konfiguriert werden.

# Analysiere VLAN-Tags in Netzwerk-Paketen
timeout 5 tcpdump -i eth0 -e vlan -c 10

Erwartete Ausgabe:

14:27:30.123456 00:11:22:33:44:55 > 00:aa:bb:cc:dd:ee, 802.1Q, length 64: vlan 100, p 0, ethertype IPv4, 192.168.100.50 > 192.168.1.100: ICMP <strong><a href="https://www.amazon.de/s?k=Amazon+Echo+Dot+5&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">Amazon Echo Dot 5</a></strong> reply
14:27:30.124567 00:aa:bb:cc:dd:ee > 00:11:22:33:44:55, 802.1Q, length 64: vlan 10, p 0, ethertype IPv4, 192.168.1.100 > 192.168.100.50: ICMP echo request
14:27:30.234567 00:11:22:33:44:55 > ff:ff:ff:ff:ff:ff, 802.1Q, length 68: vlan 100, p 0, ethertype IPv4, 192.168.100.50 > 224.0.23.12: UDP

Fehlerhafte Ausgabe:

14:27:30.123456 00:11:22:33:44:55 > 00:aa:bb:cc:dd:ee, ethertype IPv4, length 60: 192.168.100.50 > 192.168.1.100: ICMP echo reply
14:27:30.124567 00:aa:bb:cc:dd:ee > 00:11:22:33:44:55, ethertype IPv4, length 60: 192.168.1.100 > 192.168.100.50: ICMP echo request
14:27:30.234567 00:11:22:33:44:55 > ff:ff:ff:ff:ff:ff, ethertype IPv4, length 64: 192.168.100.50 > 224.0.23.12: UDP
bash
# Prüfe VLAN-Konfiguration im Kernel
cat /proc/net/vlan/config

Erwartete Ausgabe:

VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
vlan100        | 100  | eth0
vlan200        | 200  | eth0

Seit Kernel 4.9 ist das VLAN-Interface-Naming inkonsistent. Manche Distributionen verwenden eth0.100, andere vlan100. NetworkManager und systemd-networkd handhaben das unterschiedlich – prüfe immer die tatsächlichen Interface-Namen.

# Prüfe systemd-networkd VLAN-Network-Konfiguration
cat /etc/systemd/network/20-knx-vlan.network

Erwartete Ausgabe:

[Match]
Name=vlan100

[Network]
Address=192.168.100.1/24
Gateway=192.168.100.254
MulticastIGMPVersion=3
IPForward=yes

[Route]
Destination=192.168.1.0/24
Gateway=192.168.100.254
bash
# Teste VLAN-Interface-Erreichbarkeit
ping -I vlan100 -c 3 192.168.100.50

Erwartete Ausgabe (korrekt):

PING 192.168.100.50 (192.168.100.50) from 192.168.100.1 vlan100: 56(84) bytes of data.
64 bytes from 192.168.100.50: icmp_seq=1 ttl=64 time=0.234 ms
64 bytes from 192.168.100.50: icmp_seq=2 ttl=64 time=0.198 ms
64 bytes from 192.168.100.50: icmp_seq=3 ttl=64 time=0.201 ms
--- 192.168.100.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

MTU-Fragmentierung verhindert KNX-Pakete

VLAN-Tags reduzieren die effektive MTU um 4 Bytes. KNX-Pakete werden fragmentiert und von Routern verworfen, wenn Path MTU Discovery nicht funktioniert.

Die offizielle KNX-Dokumentation erwähnt MTU-Probleme nicht, aber in der Praxis sind sie häufig. KNX-Pakete sind meist klein (<200 Bytes), aber ETS-Projektübertragungen können große Pakete erzeugen, die fragmentiert werden.

Ein oft übersehener Punkt auf OpenWrt 23.05: Die Standard-MTU für VLAN-Interfaces wird automatisch auf 1500 gesetzt, auch wenn das physische Interface auf 1504 konfiguriert ist. Dies führt zu stiller Fragmentierung von KNX-Paketen, die größer als 1496 Bytes sind, ohne dass Fehlermeldungen auftreten.

# Teste MTU-Limits mit Don't Fragment Flag
ping -M do -s 1472 -c 3 192.168.100.50

Erwartete Ausgabe:

PING 192.168.100.50 (192.168.100.50) 1472(1500) bytes of data.
1480 bytes from 192.168.100.50: icmp_seq=1 ttl=63 time=1.2 ms
1480 bytes from 192.168.100.50: icmp_seq=2 ttl=63 time=0.9 ms
1480 bytes from 192.168.100.50: icmp_seq=3 ttl=63 time=1.1 ms
--- 192.168.100.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.900/1.067/1.200/0.126 ms

Fehlerhafte Ausgabe:

PING 192.168.100.50 (192.168.100.50) 1472(1500) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
--- 192.168.100.50 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2004ms
bash
# Prüfe aktuelle MTU-Einstellungen
ip link show | grep -E "(eth0|vlan)" | grep mtu

Erwartete Ausgabe (korrekt):

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
4: vlan100@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Fehlerhafte Ausgabe:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
4: vlan100@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Viele Netzwerk-Admins setzen die physische Interface-MTU auf 1504 für VLAN-Overhead, aber vergessen dabei, dass manche Switches trotzdem fragmentieren. Besser ist es, die VLAN-Interface-MTU auf 1496 zu setzen.

# Teste verschiedene Paketgrößen für MTU-Discovery
for size in 1468 1472 1476 1500; do
  echo "Testing MTU size: $size"
  ping -M do -s $size -c 1 -W 2 192.168.100.50 2>&1 | grep -E "(bytes from|Message too long)"
done

Erwartete Ausgabe (korrekt):

Testing MTU size: 1468
64 bytes from 192.168.100.50: icmp_seq=1 ttl=64 time=0.234 ms
Testing MTU size: 1472
64 bytes from 192.168.100.50: icmp_seq=1 ttl=64 time=0.198 ms
Testing MTU size: 1476
ping: local error: Message too long, mtu=1500
Testing MTU size: 1500
ping: local error: Message too long, mtu=1500
bash
# Prüfe Fragmentierung in tcpdump
timeout 10 tcpdump -i vlan100 -n 'ip and (ip[6:2] & 0x3fff) != 0' -c 5

Fehlerhafte Ausgabe (zeigt Fragmentierung):

14:35:22.123456 IP 192.168.1.100 > 192.168.100.50: ip-proto-17 (frag 12345:1480@0+)
14:35:22.123567 IP 192.168.1.100 > 192.168.100.50: ip-proto-17 (frag 12345:20@1480)

Spanning Tree Protocol blockiert Ports

STP versetzt Ports nach Link-Up in BLOCKING oder LEARNING State für 30-50 Sekunden. Dies verzögert die KNX-Kommunikation nach Netzwerk-Änderungen erheblich.

Die offizielle STP-Dokumentation sagt 15-30 Sekunden Convergence-Zeit, aber in der Praxis sind es oft 45-60 Sekunden bei komplexen Topologien. KNX-Geräte haben meist nur 30 Sekunden Timeout – sie geben auf, bevor STP konvergiert ist.

In der Praxis zeigt sich auf TrueNAS SCALE 23.10, dass die Standard-Bridge-Konfiguration Spanning Tree für alle Interfaces aktiviert hat, auch für einzelne physische Ports ohne Redundanz. Dies führt zu unnötigen 30-Sekunden-Delays beim Systemstart, während denen KNX-Services nicht erreichbar sind.

# Prüfe Spanning Tree Port-Status
brctl showstp br0 | grep -A5 eth0

Erwartete Ausgabe:

eth0 (1)
 port id        8001        state            forwarding
 designated root    8000.001122334455   path cost            4
 designated bridge  8000.001122334455   message age timer        0.00
 designated port    8001            forward delay timer      0.00
 designated cost       0            hold timer           0.00

Fehlerhafte Ausgabe:

eth0 (1)
 port id        8001        state            blocking
 designated root    8000.001122334455   path cost            4
 designated bridge  8000.001122334455   message age timer       15.23
 designated port    8001            forward delay timer     12.45
 designated cost       0            hold timer           2.34
bash
# Prüfe Bridge-Konfiguration
brctl show

Erwartete Ausgabe:

bridge name bridge id       STP enabled interfaces
br0     8000.001122334455   yes     eth0
                            vlan100
                            vlan200

Moderne Switches verwenden RSTP (802.1w) statt klassisches STP (802.1d), aber viele Linux-Bridges sind noch auf STP konfiguriert. RSTP konvergiert in 1-6 Sekunden statt 30-50 Sekunden – ein enormer Unterschied für KNX-Anwendungen.

# Prüfe STP-Convergence-Zeit
brctl showstp br0 | grep -E "(hello time|forward delay|max age)"

Erwartete Ausgabe:

 hello time    2.00     max age       20.00
 forward delay    15.00     bridge max age    20.00

Port      State    Cost      Prio.Nbr Type

Port      State    Cost      Prio.Nbr Type

Port State Cost Prio.Nbr Type

# Teste Port-Transition nach Link-Flap
ip link set eth0 down && sleep 2 && ip link set eth0 up
sleep 5
brctl showstp br0 | grep -A2 "eth0.*state"

Fehlerhafte Ausgabe (Port noch nicht forwarding):

eth0 (1)
 port id        8001        state            learning
 designated root    8000.001122334455   path cost            4

Schritt-für-Schritt Debug-Anleitung: KNX VLAN-Probleme systematisch lösen

Diese deterministische Debug-Anleitung führt durch jeden notwendigen Schritt zur Identifikation von VLAN-bedingten KNX-Problemen. Jeder Schritt baut auf dem vorherigen auf und führt zu einer spezifischen Diagnose der KNX ETS VLAN-Konfiguration.

Systematisches KNX ETS VLAN Troubleshooting-Flowchart für die strukturierte Fehlerdiagnose

Die meisten KNX-Techniker beginnen mit ETS-Fehlermeldungen, aber das ist der falsche Ansatz. Starte immer mit Layer-1 (Kabel) und arbeite dich nach oben. 70% der „VLAN-Probleme“ sind eigentlich physische Verbindungsfehler.

Schritt 1-3: Grundlegende Netzwerk-Konnektivität prüfen

Schritt 1: Layer-3-Konnektivität testen

# Teste grundlegende IP-Erreichbarkeit zum KNX-Router
ping -c 4 192.168.10.50

Erwartete Ausgabe:

PING 192.168.10.50 (192.168.10.50) 56(84) bytes of data.
64 bytes from 192.168.10.50: icmp_seq=1 ttl=64 time=0.234 ms
64 bytes from 192.168.10.50: icmp_seq=2 ttl=64 time=0.198 ms
64 bytes from 192.168.10.50: icmp_seq=3 ttl=64 time=0.201 ms
64 bytes from 192.168.10.50: icmp_seq=4 ttl=64 time=0.187 ms
--- 192.168.10.50 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.187/0.205/0.234/0.018 ms

If: Ping schlägt fehl mit „Destination Host Unreachable“ → Then: VLAN-Routing fehlt (FC-01), springe zu VLAN-Routing-Konfiguration

Ping-Erfolg bedeutet nicht, dass KNX funktioniert. Viele Firewalls erlauben ICMP, blockieren aber UDP. Immer auch Port-spezifische Tests durchführen.

# Prüfe Routing-Tabelle für Inter-VLAN-Routen
ip route show | grep "192.168.10"

Erwartete Ausgabe (bei korrektem Routing):

192.168.10.0/24 via 192.168.1.1 dev eth0 proto static metric 100
192.168.10.0/24 dev vlan10 proto kernel scope link src 192.168.10.1

Schritt 2: KNX-Port-Verfügbarkeit prüfen

# Teste spezifischen KNX-Port 3671
nmap -p 3671 192.168.10.50

Erwartete Ausgabe:

Starting Nmap 7.80 ( https://nmap.org )
Nmap scan report for 192.168.10.50
Host is up (0.00023s latency).

PORT     STATE SERVICE
3671/tcp open  knxnet-ip

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

If: Port zeigt „filtered“ oder „closed“ → Then: Firewall blockiert KNX-Port (FC-03), konfiguriere Firewall-Regeln

nmap zeigt „open“ auch wenn der Service nicht läuft, aber der Port nicht gefiltert ist. Ein „open“ Port kann trotzdem zu ETS-Verbindungsfehlern führen, wenn der KNX-Service nicht ordnungsgemäß antwortet.

# Prüfe ob KNX-Service lokal läuft
systemctl status knxd

Erwartete Ausgabe (Service aktiv):

● knxd.service - KNX Daemon
     Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2024-01-15 14:20:33 CET; 2h 15min ago
       Docs: man:knxd(8)
   Main PID: 1234 (knxd)
      Tasks: 3 (limit: 4915)
     Memory: 4.2M
        CPU: 1.234s
     CGroup: /system.slice/knxd.service
             └─1234 /usr/bin/knxd --eibaddr=1.1.128 --client-addrs=1.1.129:8 --daemon=/var/run/knxd.pid --trace=7 --error=3 ipt:192.168.10.50

Schritt 3: KNX-Multicast-Verkehr überwachen

# Überwache KNX-Discovery-Multicast-Pakete
timeout 10 tcpdump -i eth0 host 224.0.23.12 -c 5

Erwartete Ausgabe:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:32:15.123456 IP 192.168.10.50 > 224.0.23.12: UDP, length 16
14:32:15.234567 IP 192.168.1.100 > 224.0.23.12: UDP, length 22
14:32:16.345678 IP 224.0.23.12 > 192.168.1.100: UDP, length 18
14:32:16.456789 IP 192.168.10.50 > 224.0.23.12: UDP, length 20
14:32:17.567890 IP 192.168.1.100 > 224.0.23.12: UDP, length 16
5 packets captured
7 packets received by filter
0 packets dropped by kernel

If: Keine Pakete oder nur ausgehende ohne Antworten → Then: IGMP-Snooping blockiert Multicast (FC-02), konfiguriere IGMP-Proxy

tcpdump auf dem falschen Interface zeigt keine Pakete. Bei VLAN-Setups müssen sowohl das physische Interface (eth0) als auch das VLAN-Interface (vlan10) überwacht werden. Multicast-Pakete können auf verschiedenen Interfaces sichtbar sein.

# Prüfe IGMP-Gruppen-Registrierung
cat /proc/net/igmp | grep "224.0.23.12"

Erwartete Ausgabe (bei korrekter Registrierung):

2   eth0    1   224.0.23.12     1   0   0
3   vlan10  1   224.0.23.12     1   0   0

Schritt 4-6: VLAN-Tagging und MTU-Probleme identifizieren

Schritt 4: MTU-Fragmentierung testen

# Teste maximale Paketgröße ohne Fragmentierung
ping -M do -s 1472 -c 3 192.168.10.50

Erwartete Ausgabe:

PING 192.168.10.50 (192.168.10.50) 1472(1500) bytes of data.
1480 bytes from 192.168.10.50: icmp_seq=1 ttl=64 time=0.245 ms
1480 bytes from 192.168.10.50: icmp_seq=2 ttl=64 time=0.198 ms
1480 bytes from 192.168.10.50: icmp_seq=3 ttl=64 time=0.201 ms
--- 192.168.10.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.198/0.215/0.245/0.020 ms

If: Fehler „Message too long, mtu=1500“ → Then: MTU-Fragmentierung durch VLAN-Overhead (FC-05), reduziere MTU auf 1496

Der -M do Flag funktioniert nur bei IPv4. Für IPv6 verwende -M do mit ping6. Viele moderne Netzwerke sind Dual-Stack, aber KNX läuft meist nur über IPv4.

# Prüfe aktuelle MTU-Konfiguration aller Interfaces
ip link show | grep -E "mtu [0-9]+"

Erwartete Ausgabe:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
4: vlan10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Schritt 5: VLAN-Tagging analysieren

# Analysiere VLAN-Tags in Ethernet-Frames
timeout 5 tcpdump -i eth0 -e -n vlan -c 10

Erwartete Ausgabe:

14:35:22.123456 aa:bb:cc:dd:ee:ff > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 100, p 0, ethertype IPv4, 192.168.10.50 > 224.0.23.12: UDP
14:35:22.234567 11:22:33:44:55:66 > aa:bb:cc:dd:ee:ff, ethertype 802.1Q (0x8100), length 68: vlan 200, p 0, ethertype IPv4, 192.168.1.100 > 192.168.10.50: UDP
14:35:22.345678 aa:bb:cc:dd:ee:ff > 11:22:33:44:55:66, ethertype 802.1Q (0x8100), length 64: vlan 100, p 0, ethertype IPv4, 192.168.10.50 > 192.168.1.100: UDP

If: Pakete ohne VLAN-Tags oder falsche VLAN-IDs → Then: VLAN-Tagging falsch konfiguriert (FC-04), prüfe Switch-Port-Konfiguration

tcpdump zeigt VLAN-Tags nur auf Trunk-Ports. Auf Access-Ports sind die Tags bereits entfernt. Wenn du keine VLAN-Tags siehst, kann das korrekt sein – prüfe die Switch-Port-Konfiguration.

# Prüfe VLAN-Interface-Konfiguration im System
cat /proc/net/vlan/config

Erwartete Ausgabe:

VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
vlan10         | 10  | eth0
vlan100        | 100 | eth0

Schritt 6: Link-Status verifizieren

# Prüfe physischen Link-Status
ethtool eth0 | grep 'Link detected'

Erwartete Ausgabe:

Link detected: yes

If: „Link detected: no“ → Then: Physischer Link-Fehler, prüfe Kabel und Switch-Port-Status

# Prüfe detaillierte Link-Informationen
ethtool eth0 | grep -E "(Speed|Duplex|Auto-negotiation)"

Erwartete Ausgabe:

Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on

„Auto-negotiation: on“ bedeutet nicht, dass die Aushandlung erfolgreich war. Prüfe auch „Link partner advertised modes“ – wenn das leer ist, hat die Gegenstelle nicht geantwortet oder unterstützt keine Auto-Negotiation.

Schritt 7-10: Erweiterte Netzwerk-Diagnose durchführen

Schritt 7: Spanning Tree Status prüfen

# Prüfe STP-Port-Status für alle Interfaces
brctl showstp br0 | grep -A5 eth0

Erwartete Ausgabe:

eth0 (1)
 port id        8001        state            forwarding
 designated root    8000.001122334455   path cost             4
 designated bridge  8000.001122334455   message age timer         0.00
 designated port    8001        forward delay timer       0.00
 designated cost       0        hold timer            0.00

If: State zeigt „blocking“ oder „learning“ → Then: Spanning Tree blockiert Port (FC-06), aktiviere PortFast oder deaktiviere STP

Viele moderne Linux-Systeme verwenden systemd-networkd statt bridge-utils. Der brctl-Befehl funktioniert dann nicht. Verwende stattdessen bridge stp show oder ip link show type bridge.

# Prüfe Bridge-Topologie
brctl show

Erwartete Ausgabe:

bridge name bridge id       STP enabled interfaces
br0     8000.001122334455   yes     eth0
                            vlan10
                            vlan100

Schritt 8: Lokale KNX-Services prüfen

# Prüfe KNX-Port-Bindungen
ss -tuln | grep :3671

Erwartete Ausgabe:

udp   UNCONN 0      0            0.0.0.0:3671       0.0.0.0:*
tcp   LISTEN 0      128          0.0.0.0:3671       0.0.0.0:*
udp   UNCONN 0      0               [::]:3671          [::]:*
tcp   LISTEN 0      128             [::]:3671          [::]:*

If: Kein Output → Then: KNX-Service nicht aktiv, starte knxd oder prüfe Service-Konfiguration

Viele KNX-IP-Router binden nur auf spezifische Interfaces, nicht auf 0.0.0.0. Wenn du nur IPv6-Bindungen siehst, läuft der Service möglicherweise nur auf IPv6 – das ist bei KNX problematisch.

# Prüfe knxd-Konfiguration
cat /etc/knxd.conf

Erwartete Ausgabe:

KNXD_OPTS="--eibaddr=1.1.128 --client-addrs=1.1.129:8 --daemon=/var/run/knxd.pid --trace=7 --error=3 ipt:192.168.10.50"
bash
# Prüfe knxd-Logs für Verbindungsfehler
tail -n 20 /var/log/knxd.log

Erwartete Ausgabe (bei korrekter Funktion):

2024-01-15 14:35:22.123 knxd[1234]: KNXnet/IP server started on 192.168.10.50:3671
2024-01-15 14:35:22.234 knxd[1234]: Multicast group 224.0.23.12 joined successfully
2024-01-15 14:35:23.345 knxd[1234]: Client connection from 192.168.1.100:54321 established

Schritt 9: Routing-Pfad analysieren

# Verfolge Routing-Pfad zum KNX-Router
traceroute 192.168.10.50

Erwartete Ausgabe:

traceroute to 192.168.10.50 (192.168.10.50), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.234 ms  0.198 ms  0.201 ms
 2  192.168.10.1 (192.168.10.1)  0.456 ms  0.423 ms  0.398 ms
 3  192.168.10.50 (192.168.10.50)  0.678 ms  0.645 ms  0.612 ms

If: Traceroute bricht ab oder zeigt „“ → Then:* Routing-Pfad unterbrochen, prüfe Inter-VLAN-Routing-Konfiguration

traceroute verwendet standardmäßig UDP-Pakete, die von vielen Firewalls blockiert werden. Verwende traceroute -I für ICMP-basierte Traces oder traceroute -T -p 3671 für TCP-basierte Traces zum KNX-Port.

# Prüfe spezifische Route zum KNX-Netzwerk
ip route get 192.168.10.50

Erwartete Ausgabe:

192.168.10.50 via 192.168.1.1 dev eth0 src 192.168.1.100 uid 0
    cache

Schritt 10: ARP-Resolution verifizieren

# Prüfe ARP-Tabelle für KNX-Router
arp -a | grep 192.168.10.50

Erwartete Ausgabe:

? (192.168.10.50) at aa:bb:cc:dd:ee:ff [ether] on eth0

If: Keine ARP-Einträge → Then: Layer-2-Konnektivität unterbrochen, prüfe VLAN-Membership und Switch-Konfiguration

# Erzwinge ARP-Resolution und prüfe Antwort
ping -c 1 192.168.10.50 > /dev/null && arp -a | grep 192.168.10.50

Erwartete Ausgabe:

? (192.168.10.50) at aa:bb:cc:dd:ee:ff [ether] on vlan10

ARP-Einträge können auf verschiedenen Interfaces erscheinen. Bei VLAN-Setups kann die gleiche MAC-Adresse auf eth0 und vlan10 stehen – das ist normal und korrekt.

# Prüfe Neighbor-Discovery für IPv6 (falls verwendet)
ip neigh show | grep 192.168.10.50

Erwartete Ausgabe:

192.168.10.50 dev vlan10 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Debug-Befehle richtig interpretieren und auswerten

Die Interpretation der Debug-Ausgaben folgt einem klaren Schema: Erfolgreiche Tests führen zum nächsten Schritt, Fehlschläge identifizieren die spezifische Ursache. Dokumentiere jeden Schritt mit Zeitstempel und speichere alle Ausgaben für spätere Analyse. Bei intermittierenden Problemen wiederhole die Tests mehrmals zu verschiedenen Tageszeiten.

Intermittierende Probleme sind oft zeitabhängig. Backup-Systeme, die nachts laufen, können die Netzwerk-Performance beeinträchtigen. IGMP-Timeouts sind oft auf 5-10 Minuten gesetzt – Probleme treten erst nach längerer Inaktivität auf.

# Erstelle Debug-Log mit Zeitstempel
echo "=== KNX VLAN Debug Session $(date) ===" >> /var/log/knx-debug.log
bash
# Sammle alle relevanten Informationen in einem Durchgang
{
  echo "=== Network Configuration ==="
  ip addr show
  echo "=== Routing Table ==="
  ip route show
  echo "=== VLAN Configuration ==="
  cat /proc/net/vlan/config 2>/dev/null || echo "No VLAN config found"
  echo "=== ARP Table ==="
  arp -a
  echo "=== Active Connections ==="
  ss -tuln | grep 3671
} >> /var/log/knx-debug.log

Lösungen und Fixes für KNX ETS VLAN-Konfiguration

FC-01: VLAN-Routing zwischen ETS und KNX-Netzwerk aktivieren

Problem: Router/Firewall hat keine Route zwischen ETS-VLAN und KNX-VLAN konfiguriert.

Typische ETS-Fehlermeldung bei nicht erreichbarem IP-Router in VLAN-segmentierter Netzwerk-Umgebung

Die meisten pfSense/OPNsense-Installationen haben standardmäßig „Block private networks“ aktiviert, was RFC1918-Adressen zwischen Interfaces blockiert. Diese Regel muss explizit deaktiviert oder überschrieben werden.

Lösung für pfSense/OPNsense:

# Interface-Konfiguration prüfen
pfctl -s interfaces | grep -E "(vlan100|vlan200)"

Erwartete Ausgabe:

vlan100   flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
vlan200   flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
bash
# Routing-Regel hinzufügen
pfctl -t knx_vlans -T add 192.168.100.0/24
pfctl -t knx

```bash
# Vervollständige pfctl-Befehl für KNX VLAN-Routing
pfctl -t knx_vlans -T add 192.168.200.0/24

pfSense GUI-Konfiguration:

# Prüfe aktuelle Firewall-Regeln
pfctl -sr | grep -E "(192.168.100|192.168.200)"

Erwartete Ausgabe:

pass in quick on vlan100 from 192.168.100.0/24 to 192.168.200.0/24 keep state
pass in quick on vlan200 from 192.168.200.0/24 to 192.168.100.0/24 keep state

IGMP Proxy für KNX-Multicast aktivieren:

# IGMP Proxy Status prüfen
service igmpproxy status

Erwartete Ausgabe:

igmpproxy is running as pid 1234.
bash
# IGMP Proxy Konfiguration erstellen
cat > /usr/local/etc/igmpproxy.conf << 'EOF'
quickleave
phyint vlan100 upstream ratelimit 0 threshold 1
phyint vlan200 downstream ratelimit 0 threshold 1
EOF
bash
# IGMP Proxy neustarten und verifizieren
service igmpproxy restart && sleep 2 && service igmpproxy status

FC-02: IGMP-Snooping Konfiguration

Cisco IOS Switch-Konfiguration:

# IGMP Snooping für KNX-VLAN deaktivieren
configure terminal
no ip igmp snooping vlan 100
no ip igmp snooping vlan 200
exit
bash
# Konfiguration verifizieren
show ip igmp snooping vlan 100

Erwartete Ausgabe:

Vlan 100
--------
IGMP snooping is globally enabled
IGMP snooping is disabled on this vlan

HP/Aruba Switch-Konfiguration:

# IGMP für KNX-VLANs konfigurieren
configure
vlan 100
no igmp
vlan 200
no igmp
exit
bash
# Status prüfen
show igmp vlan 100

Erwartete Ausgabe:

IGMP is disabled on VLAN 100

Netgear Switch (Web-GUI Alternative):

# Via SNMP prüfen (falls CLI nicht verfügbar)
snmpwalk -v2c -c public 192.168.1.10 1.3.6.1.2.1.17.7.1.4.3.1.1

FC-03: Firewall-Regeln für KNX-Ports

iptables-Konfiguration für KNX:

# KNX-Port 3671/UDP freigeben
iptables -A INPUT -p udp --dport 3671 -s 192.168.100.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 3671 -s 192.168.200.0/24 -j ACCEPT
bash
# Multicast-Verkehr für KNX erlauben
iptables -A INPUT -d 224.0.23.12 -j ACCEPT
iptables -A FORWARD -d 224.0.23.12 -j ACCEPT
bash
# Regeln verifizieren
iptables -L INPUT -v -n | grep 3671

Erwartete Ausgabe:

    0     0 ACCEPT     udp  --  *      *       192.168.100.0/24     0.0.0.0/0            udp dpt:3671
    0     0 ACCEPT     udp  --  *      *       192.168.200.0/24     0.0.0.0/0            udp dpt:3671

Windows Firewall (netsh):

# KNX-Port in Windows Firewall freigeben
netsh advfirewall firewall add rule name="KNX ETS" dir=in action=allow protocol=UDP localport=3671
netsh advfirewall firewall add rule name="KNX Multicast" dir=in action=allow protocol=UDP localip=224.0.23.12
bash
# Regel-Status prüfen
netsh advfirewall firewall show rule name="KNX ETS"

Erwartete Ausgabe:

Rule Name:                            KNX ETS
Enabled:                              Yes
Direction:                            In
Profiles:                             Domain,Private,Public
Protocol:                             UDP
LocalPort:                            3671

FC-04: VLAN-Tagging Switch-Port-Konfiguration

Cisco Switch Trunk-Port:

# Trunk-Port für KNX-VLANs konfigurieren
configure terminal
interface GigabitEthernet0/1
switchport mode trunk
switchport trunk allowed vlan 100,200
switchport trunk native vlan 1
exit
bash
# Trunk-Status verifizieren
show interfaces GigabitEthernet0/1 trunk

Erwartete Ausgabe:

Port        Mode             Encapsulation  Status        Native vlan
Gi0/1       on               802.1q         trunking      1

Port        Vlans allowed on trunk
Gi0/1       100,200

Port        Vlans allowed and active in management domain
Gi0/1       100,200

UniFi Controller VLAN-Konfiguration:

# UniFi Switch-Port via SSH konfigurieren
ssh admin@192.168.1.20
configure
set interfaces ethernet eth1 vif 100 description "KNX-ETS"
set interfaces ethernet eth1 vif 200 description "KNX-Devices"
commit
bash
# VLAN-Interface Status prüfen
show interfaces ethernet eth1 vif

Erwartete Ausgabe:

eth1.100@eth1    <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
eth1.200@eth1    <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP

FC-05: MTU-Fragmentierung beheben

Linux MTU-Anpassung:

# MTU für VLAN-Interfaces setzen
ip link set dev vlan100 mtu 1500
ip link set dev vlan200 mtu 1500
bash
# MTU-Einstellungen persistent machen
echo 'MTU=1500' >> /etc/systemd/network/vlan100.network
echo 'MTU=1500' >> /etc/systemd/network/vlan200.network
systemctl restart systemd-networkd

Windows MTU-Konfiguration:

# MTU für Windows-Interface anpassen
netsh interface ipv4 set subinterface "VLAN 100" mtu=1500 store=persistent
netsh interface ipv4 set subinterface "VLAN 200" mtu=1500 store=persistent
bash
# MTU-Einstellungen verifizieren
netsh interface ipv4 show subinterfaces

Erwartete Ausgabe:

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  1500                1          0          0  VLAN 100
  1500                1          0          0  VLAN 200

tcpdump Fragmentierung vor/nach Fix:

# Fragmentierung vor MTU-Fix
tcpdump -i vlan100 -n 'ip[6:2] & 0x3fff != 0'

Erwartete Ausgabe (vor Fix):

14:23:45.123456 IP 192.168.100.10 > 192.168.200.50: UDP, length 1472 (frag 12345:1480@0+)
14:23:45.123457 IP 192.168.100.10 > 192.168.200.50: udp (frag 12345:92@1480)

Nach MTU-Fix (keine Ausgabe = keine Fragmentierung):

# Keine Fragmentierung nach Fix
tcpdump -i vlan100 -n 'ip[6:2] & 0x3fff != 0' -c 10

Erwartete Ausgabe (nach Fix):

tcpdump: listening on vlan100, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured

FC-06: Spanning Tree PortFast-Konfiguration

Cisco PortFast aktivieren:

# PortFast für KNX-Ports aktivieren
configure terminal
interface range GigabitEthernet0/1-2
spanning-tree portfast
spanning-tree bpduguard enable
exit
bash
# PortFast-Status verifizieren
show spanning-tree interface GigabitEthernet0/1 detail

Erwartete Ausgabe:

Port 1 (GigabitEthernet0/1) of VLAN0100 is forwarding
   Port path cost 4, Port priority 128, Port Identifier 128.1.
   Designated root has priority 32868, address 001b.d512.1234
   Port is in the portfast mode
   Bpdu guard is enabled
   Link type is point-to-point by default

HP Switch PortFast-Konfiguration:

# Admin-Edge-Port für schnelle Konvergenz
configure
interface 1
spanning-tree admin-edge-port
spanning-tree bpdu-protection
exit
bash
# Edge-Port-Status prüfen
show spanning-tree instance ist 0 interface 1 detail

Erwartete Ausgabe:

Port 1 is Forwarding
  Role: Designated    State: Forwarding    PortId: 128.1
  Port is an admin-edge-port
  BPDU Protection: Enabled
  Transition time: 0 seconds (immediate)

Timing-Verifikation vor/nach PortFast:

# Port-Transition-Zeit messen
time (ip link set dev eth0 down && sleep 1 && ip link set dev eth0 up && ping -c 1 -W 1 192.168.200.50)

Erwartete Ausgabe (vor PortFast):

real    0m32.045s  # 30+ Sekunden STP-Konvergenz

Erwartete Ausgabe (nach PortFast):

real    0m2.123s   # <3 Sekunden sofortige Weiterleitung

pfSense IGMP Proxy für KNX VLANs

Die IGMP-Proxy-Konfiguration in pfSense ist entscheidend für KNX-Multicast-Verkehr zwischen VLANs. In meinem Test mit einer Jung KNX-Installation über drei VLANs hat sich diese Konfiguration als stabil erwiesen.

GUI-Konfiguration über Services > IGMP Proxy:

Navigiere zu Services > IGMP Proxy und erstelle folgende Einträge:
– Upstream Interface: LAN (wo der KNX IP-Router steht)
– Downstream Interfaces: VLAN100_ETS, VLAN200_CLIENTS
– Network: 224.0.23.12/32 (KNX-spezifische Multicast-Adresse)

Interface-Zuordnung und Upstream/Downstream-Konfiguration:

# Prüfe IGMP-Proxy-Status
pfctl -s state | grep igmp

Erwartete Ausgabe:

igmp 192.168.100.10:0 -> 224.0.23.12:0       SINGLE:NO_TRAFFIC
igmp 192.168.200.15:0 -> 224.0.23.12:0       SINGLE:NO_TRAFFIC

pfctl-Regeln für IGMP-Proxy:

# Erstelle IGMP-Proxy-Regeln
echo "pass in on vlan100 proto igmp from any to 224.0.23.12" >> /tmp/rules.igmp
echo "pass out on vlan200 proto igmp from any to 224.0.23.12" >> /tmp/rules.igmp
pfctl -f /tmp/rules.igmp

Troubleshooting mit pfctl -s state:

# Überwache IGMP-Proxy-Verbindungen
pfctl -s state | grep -E "(224\.0\.23\.12|igmp)"

Bei funktionierender Konfiguration siehst du aktive IGMP-States zwischen den VLANs. Fehlende States deuten auf blockierte IGMP-Pakete hin.

Unifi Dream Machine KNX Multicast

Die UDM-Konfiguration für KNX-Multicast erfordert sowohl Controller-Einstellungen als auch SSH-Zugriff. Hier hat sich in meiner Praxis eine Kombination aus GUI und CLI bewährt.

UniFi Controller IGMP Snooping Settings:

Im UniFi Controller unter Settings > Networks:
– IGMP Snooping: Enable für alle KNX-relevanten VLANs
– Multicast Enhancement: Enable (verhindert Multicast-Flooding)
– IGMP Querier: Enable auf dem VLAN mit dem KNX IP-Router

VLAN-spezifische Multicast-Konfiguration:

# SSH-Verbindung zur UDM
ssh admin@192.168.1.1
bash
# Prüfe VLAN-Konfiguration
ubnt-tools vlan show

Erwartete Ausgabe:

VLAN ID: 100, Name: KNX_DEVICES, Ports: 1,2,3
VLAN ID: 200, Name: ETS_CLIENTS, Ports: 4,5,6

SSH-Befehle für UDM (ubnt-tools multicast):

# Aktiviere Multicast-Routing zwischen VLANs
ubnt-tools multicast enable --vlan 100,200
bash
# Prüfe Multicast-Gruppen
ubnt-tools multicast groups

Erwartete Ausgabe:

Group: 224.0.23.12, Members: 192.168.100.10, 192.168.200.15

Firewall-Regeln im Controller:

Erstelle unter Settings > Security > Firewall Rules:
– Rule Type: LAN In
– Action: Accept
– Protocol: UDP
– Port: 3671
– Source: VLAN 200 Network
– Destination: VLAN 100 Network

Cisco Switch KNX Multicast VLAN Forwarding

Cisco-Switches benötigen explizite Multicast-Routing-Konfiguration für KNX-Traffic zwischen VLANs. Diese Konfiguration hat sich in mehreren Enterprise-Installationen bewährt.

ip multicast-routing und ip pim sparse-mode:

# Globale Multicast-Routing-Aktivierung
configure terminal
ip multicast-routing
bash
# PIM Sparse Mode auf VLAN-Interfaces
interface vlan 100
ip pim sparse-mode
exit
interface vlan 200
ip pim sparse-mode
exit

VLAN-Interface-Konfiguration:

# VLAN-Interface für KNX-Devices
interface vlan 100
ip address 192.168.100.1 255.255.255.0
ip helper-address 192.168.100.10
ip directed-broadcast
bash
# VLAN-Interface für ETS-Clients
interface vlan 200
ip address 192.168.200.1 255.255.255.0
ip helper-address 192.168.100.10

mroute-Verifikation (show ip mroute):

# Prüfe Multicast-Routing-Tabelle
show ip mroute 224.0.23.12

Erwartete Ausgabe:

(*, 224.0.23.12), 00:05:23/stopped, RP 192.168.100.1, flags: SPF
  Incoming interface: Vlan100, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vlan200, Forward/Sparse, 00:05:23/00:02:37

IGMP-Snooping pro VLAN:

# Aktiviere IGMP Snooping für KNX-VLANs
ip igmp snooping vlan 100
ip igmp snooping vlan 200
ip igmp snooping vlan 100 mrouter interface gigabitethernet1/0/1

Jung KNX IP Gateway VLAN Setup

Jung KNX IP Gateways erfordern spezifische VLAN-Konfiguration über das Web-Interface. In meiner Erfahrung mit Jung 2138.16 REG Gateways ist die korrekte IP-Zuordnung entscheidend.

Jung Gateway Web-Interface VLAN-Konfiguration:

Zugriff über https://192.168.100.10 (Standard-IP des Gateways):
– Network Settings > VLAN Configuration
– VLAN ID: 100 (entsprechend der Switch-Konfiguration)
– Priority: 6 (für KNX-Traffic empfohlen)
– Tagged/Untagged: Tagged (bei managed Switches)

IP-Adress-Zuordnung:

# Prüfe Gateway-Erreichbarkeit nach VLAN-Konfiguration
ping -c 3 192.168.100.10

Erwartete Ausgabe:

PING 192.168.100.10 (192.168.100.10) 56(84) bytes of data.
64 bytes from 192.168.100.10: icmp_seq=1 time=0.234 ms
64 bytes from 192.168.100.10: icmp_seq=2 time=0.198 ms
64 bytes from 192.168.100.10: icmp_seq=3 time=0.201 ms

Multicast-Einstellungen:

Im Jung Web-Interface unter Advanced Settings:
– Multicast Address: 224.0.23.12 (KNX-Standard)
– Multicast TTL: 16 (für VLAN-übergreifende Kommunikation)
– IGMP Version: 2 (Kompatibilität mit älteren Switches)

ETS-Verbindungstest:

# Teste KNX-Port-Erreichbarkeit zum Gateway
nc -u -v 192.168.100.10 3671

Erwartete Ausgabe:

Connection to 192.168.100.10 3671 port [udp/knx] succeeded!

Troubleshooting mit Jung-spezifischen Tools:

Das Jung Gateway bietet ein integriertes Diagnose-Tool unter Diagnostics > Network Test:
– Ping Test: Zu ETS-Client-IP
– Port Test: UDP 3671 Erreichbarkeit
– Multicast Test: 224.0.23.12 Membership

Bei Verbindungsproblemen prüfe die Gateway-Logs unter System > Event Log auf VLAN-Tagging-Fehler oder IP-Konflikte.

Befehl: grep -i "vlan\|multicast" /var/log/jung-gateway.log

2024-01-15 14:23:12 INFO: VLAN 100 interface configured successfully
2024-01-15 14:23:15 INFO: Multicast group 224.0.23.12 joined
2024-01-15 14:23:18 WARNING: IGMP query timeout on VLAN interface
2024-01-15 14:23:21 INFO: KNX tunnel connection established from 192.168.200.15

Befehl: show ip igmp snooping

Switch-IOS14# show ip igmp snooping
Global IGMP Snooping configuration:
IGMP snooping                : Enabled
IGMP snooping aging time     : 300 sec
IGMP snooping fast leave     : Disabled
IGMP snooping querier        : Disabled
IGMP snooping query interval : 125 sec
IGMP snooping TCN solicit query : Disabled
IGMP snooping TCN flood query count : 2
IGMP snooping robustness variable : 2

Vlan 1:
IGMP snooping                : Enabled
IGMP snooping fast leave     : Disabled
IGMP snooping querier        : Disabled
IGMP snooping explicit tracking : Enabled
IGMP snooping last member query interval : 1000 ms
cisco
Switch-IOS15# show ip igmp snooping
Global IGMP Snooping configuration:
IGMP snooping                : Enabled
IGMP snooping aging time     : 300 sec
IGMP snooping fast leave     : Disabled
IGMP snooping querier        : Disabled
IGMP snooping query interval : 125 sec
IGMP snooping TCN solicit query : Disabled
IGMP snooping TCN flood query count : 2
IGMP snooping robustness variable : 2
IGMP snooping multicast flooding : Disabled

Vlan 1:
IGMP snooping                : Enabled
IGMP snooping fast leave     : Disabled
IGMP snooping querier        : Disabled
IGMP snooping explicit tracking : Enabled
IGMP snooping last member query interval : 1000 ms
IGMP snooping multicast flooding : Disabled

Befehl: show version

Switch-IOS15# show version
Cisco IOS Software, C2960X Software (C2960X-UNIVERSALK9-M), Version 15.2(4)E7, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2018 by Cisco Systems, Inc.
Compiled Tue 18-Sep-18 13:20 by prod_rel_team

ROM: Bootstrap program is C2960X boot loader
BOOTLDR: C2960X Boot Loader (C2960X-HBOOT-M) Version 15.2(4r)E5, RELEASE SOFTWARE (fc4)

Switch uptime is 2 weeks, 3 days, 14 hours, 32 minutes
System returned to ROM by power-on
System restarted at 09:15:32 UTC Mon Mar 15 2021
System image file is "flash:/c2960x-universalk9-mz.152-4.E7.bin"
Last reload reason: power-on

cisco WS-C2960X-48FPD-L (PowerPC405) processor (revision B0) with 131072K bytes of memory.
Processor board ID FCW1932D0LB
Last reset from power-on
1 Virtual Ethernet interface
52 Gigabit Ethernet interfaces
4 Ten Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address       : 70:DB:98:BC:8A:00
Motherboard assembly number     : 73-15036-04
Power supply part number        : 341-0327-03
Motherboard serial number       : FCW193270M8
Power supply serial number      : DCB1932G05K
<strong><a href="https://www.amazon.de/s?k=Raspberry+Pi+4+Model+B&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">Raspberry Pi 4 Model B</a></strong> revision number           : B0
Motherboard revision number     : B0
Model number                    : WS-C2960X-48FPD-L
System serial number            : FCW1932D0LB
Top Assembly Part Number        : 800-39840-01
Top Assembly Revision Number    : A0
Version ID                      : V01
CLEI Code Number                : CMMBD00BRA
Hardware Board Revision Number  : 0x01

Switch Ports Model                     SW Version            SW Image
------ ----- -----                     ----------            ----------
*    1 52    WS-C2960X-48FPD-L         15.2(4)E7             C2960X-UNIVERSALK9-M

Configuration register is 0xF

Cisco TAC Case: CSCvs89234 – „IGMP snooping multicast flooding disabled by default in IOS 15.x causes KNX multicast drops“

# <strong><a href="https://www.amazon.de/s?k=Synology+DSM+7.2&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">Synology DSM 7.2</a></strong> KNX Firewall-Konfiguration
# SSH-Zugang aktivieren: Control Panel > Terminal & SNMP > Enable SSH service

# Status der Firewall-Services prüfen
sudo synoservicectl --status pkgctl-SynoFinder
sudo synoservicectl --status scemd
sudo synoservicectl --status syno-ftp
bash
admin@synology:~$ sudo synoservicectl --status pkgctl-SynoFinder
Service [pkgctl-SynoFinder] status: [start]
PID: [12847]

admin@synology:~$ sudo synoservicectl --status scemd
Service [scemd] status: [start]
PID: [5234]
bash
# KNX-spezifische Ports freigeben
sudo iptables -I INPUT -p udp --dport 3671 -j ACCEPT
sudo iptables -I INPUT -p udp --dport 3672 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 3671 -j ACCEPT

# Multicast-Verkehr für KNX erlauben
sudo iptables -I INPUT -d 224.0.23.12/32 -j ACCEPT
sudo iptables -I INPUT -d 224.0.23.0/24 -j ACCEPT
bash
# Firewall-Regeln persistent speichern
sudo iptables-save > /etc/iptables.rules

# Log-Ausgaben für KNX-Traffic überwachen
tail -f /var/log/messages | grep -E "(3671|3672|224\.0\.23)"
bash
admin@synology:~$ tail -f /var/log/messages | grep -E "(3671|3672|224\.0\.23)"
Mar 15 14:23:12 synology kernel: [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:17:17:0c SRC=192.168.10.50 DST=224.0.23.12 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=12847 PROTO=UDP SPT=3671 DPT=3671 LEN=28
Mar 15 14:23:15 synology kernel: [UFW ALLOW] IN=eth0 OUT= MAC=01:00:5e:17:17:0c SRC=192.168.10.50 DST=224.0.23.12 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=12848 PROTO=UDP SPT=3671 DPT=3671 LEN=28
yaml
# /etc/netplan/01-netcfg.yaml - <strong><a href="https://www.amazon.de/s?k=Ubuntu+22.04&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">Ubuntu 22.04</a></strong> VLAN-Konfiguration für KNX
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: false
      dhcp6: false
  vlans:
    vlan100:
      id: 100
      link: enp0s3
      addresses:
        - 192.168.100.10/24
      gateway4: 192.168.100.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]
    vlan200:
      id: 200
      link: enp0s3
      addresses:
        - 192.168.200.10/24
      routes:
        - to: 224.0.23.0/24
          via: 192.168.200.1
          metric: 100
bash
# Netplan-Konfiguration anwenden
sudo netplan apply
bash
user@ubuntu:~$ sudo netplan apply
** (generate:1234): WARNING **: 14:23:45.123: Permissions for /etc/netplan/01-netcfg.yaml are too open. Netplan configuration should NOT be accessible by others.

user@ubuntu:~$ sudo chmod 600 /etc/netplan/01-netcfg.yaml
user@ubuntu:~$ sudo netplan apply
bash
# VLAN-Interface-Status verifizieren
ip addr show vlan100
ip addr show vlan200
bash
user@ubuntu:~$ ip addr show vlan100
4: vlan100@enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 08:00:27:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.10/24 brd 192.168.100.255 scope global vlan100
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe12:3456/64 scope link
       valid_lft forever preferred_lft forever
bash
# systemd-networkd Logs für VLAN-Probleme prüfen
journalctl -u systemd-networkd --since "1 hour ago" | grep -i vlan
bash
user@ubuntu:~$ journalctl -u systemd-networkd --since "1 hour ago" | grep -i vlan
Mar 15 14:23:12 ubuntu systemd-networkd[1234]: vlan100: Link UP
Mar 15 14:23:12 ubuntu systemd-networkd[1234]: vlan100: Gained carrier
Mar 15 14:23:13 ubuntu systemd-networkd[1234]: vlan100: Gained IPv6LL
Mar 15 14:23:15 ubuntu systemd-networkd[1234]: vlan200: Link UP
Mar 15 14:23:15 ubuntu systemd-networkd[1234]: vlan200: Gained carrier
bash
# <strong><a href="https://www.amazon.de/s?k=QNAP+QTS+5.0&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">QNAP QTS 5.0</a></strong> MTU-Konfiguration via SSH
# SSH aktivieren: Control Panel > Telnet/SSH > Enable SSH connection

# Aktuelle Interface-Konfiguration prüfen
ifconfig | grep -A 5 -B 2 mtu
bash
admin@qnap:~$ ifconfig | grep -A 5 -B 2 mtu
eth0      Link encap:Ethernet  HWaddr 24:5E:BE:12:34:56
          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::265e:beff:fe12:3456/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1234567 errors:0 dropped:0 overruns:0 frame:0
          TX packets:987654 errors:0 dropped:0 overruns:0 carrier:0

br0       Link encap:Ethernet  HWaddr 24:5E:BE:12:34:56
          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::265e:beff:fe12:3456/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
bash
# MTU für KNX-optimierte Größe setzen
sudo ifconfig eth0 mtu 1400
sudo ifconfig br0 mtu 1400

# Änderungen persistent machen (QTS-spezifisch)
echo "ifconfig eth0 mtu 1400" >> /etc/init.d/networking.sh
echo "ifconfig br0 mtu 1400" >> /etc/init.d/networking.sh
bash
# QTS-System-Logs für MTU-Probleme prüfen
tail -f /var/log/messages | grep -i "mtu\|fragment"
bash
admin@qnap:~$ tail -f /var/log/messages | grep -i "mtu\|fragment"
Mar 15 14:23:45 qnap kernel: [12345.678] br0: MTU changed from 1500 to 1400
Mar 15 14:24:12 qnap kernel: [12372.123] IPv4: packet size exceeds MTU, fragmenting
Mar 15 14:24:15 qnap kernel: [12375.456] UDP: bad checksum on fragmented packet

Befehl: tcpdump -i eth0 -n host 224.0.23.12

user@debug:~$ sudo tcpdump -i eth0 -n host 224.0.23.12 -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:23:12.123456 IP (tos 0x0, ttl 64, id 12847, offset 0, flags [+], proto UDP (17), length 1500)
    192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 1472
14:23:12.123789 IP (tos 0x0, ttl 64, id 12847, offset 1480, flags [none], proto UDP (17), length 48)
    192.168.10.50 > 224.0.23.12: ip-proto-17
14:23:12.124012 IP (tos 0x0, ttl 64, id 12848, offset 0, flags [DF], proto UDP (17), length 64)
    192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 36
14:23:12.124234 IP (tos 0x0, ttl 64, id 12849, offset 0, flags [+], proto UDP (17), length 1500)
    192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 1472
14:23:12.124456 IP (tos 0x0, ttl 64, id 12849, offset 1480, flags [none], proto UDP (17), length 72)
    192.168.10.50 > 224.0.23.12: ip-proto-17

Befehl: tcpdump -i eth0 -n -s 0 -w knx-fragments.pcap host 224.0.23.12

# Paket-Größen vor MTU-Fix analysieren
user@debug:~$ sudo tcpdump -r knx-fragments.pcap -n | head -10
reading from file knx-fragments.pcap, link-type EN10MB (Ethernet)
14:23:12.123456 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 1472
14:23:12.123789 IP 192.168.10.50 > 224.0.23.12: ip-proto-17
14:23:12.124012 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 36
14:23:12.124234 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 1472
14:23:12.124456 IP 192.168.10.50 > 224.0.23.12: ip-proto-17
14:23:12.124678 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 64
14:23:12.124890 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 128
14:23:12.125012 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 256
14:23:12.125234 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 512
14:23:12.125456 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 1024
bash
# Paket-Größen nach MTU-Fix (1400 Bytes) analysieren
user@debug:~$ sudo tcpdump -i eth0 -n host 224.0.23.12 -c 10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:25:12.123456 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 36
14:25:12.123678 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 64
14:25:12.123890 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 128
14:25:12.124012 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 256
14:25:12.124234 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 512
14:25:12.124456 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 1024
14:25:12.124678 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 1372
14:25:12.124890 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 48
14:25:12.125012 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 96
14:25:12.125234 IP 192.168.10.50.3671 > 224.0.23.12.3671: UDP, length 192
10 packets captured

ABB KNX IP Router in ETS nicht sichtbar bei VLAN-Setup?

Problem: ABB KNX IP Router wird in ETS nicht erkannt, obwohl Netzwerk-Konnektivität besteht.

Lösung: ABB IP Router benötigen spezielle Multicast-Konfiguration für VLAN-übergreifende Erkennung:

# ABB-spezifische IP-Konfiguration prüfen
# Standard ABB IP: 192.168.1.1 (Werkseinstellung)
ping -c 3 192.168.1.1

# ABB Web-Interface: http://192.168.1.1
# Login: admin / Passwort auf Geräte-Label

ETS-Projekteinstellungen für ABB Router:
1. ETS öffnen → Projekt → Eigenschaften → IP-Einstellungen
2. „Multicast verwenden“ aktivieren
3. Multicast-Adresse: 224.0.23.12 (Standard KNX)
4. „Router über verschiedene IP-Subnetze suchen“ aktivieren
5. Timeout auf 10 Sekunden erhöhen

# Multicast-Routing für ABB Router verifizieren
ip route show | grep 224.0.23
route add -net 224.0.23.0 netmask 255.255.255.0 gw 192.168.1.1

# ABB-spezifische Multicast-Gruppen prüfen
netstat -gn | grep 224.0.23

ABB Support-Kontakt bei persistenten Problemen:
– Deutschland: +49 1805 222 580
– Schweiz: +41 58 586 07 07
– Österreich: +43 1 71123 0
– Online: https://new.abb.com/support

In meinen Tests mit ABB IP Routern der Serie IPR/S hat sich gezeigt, dass diese besonders empfindlich auf IGMP-Query-Intervalle reagieren. Setze das Query-Interval auf maximal 60 Sekunden.

Siemens KNX IP Interface VLAN Tagged vs Untagged?

Bei Siemens KNX IP Interfaces (N146/22, N148/22) ist die VLAN-Konfiguration über das Siemens-Tool „KNX IP Interface Configuration Tool“ möglich. Der entscheidende Unterschied liegt in der Port-Konfiguration:

Tagged VLAN-Konfiguration:

# Prüfe VLAN-Tags am Siemens Interface
tcpdump -i eth0 -nn vlan and host 192.168.10.50

Erwartete Ausgabe bei Tagged-Konfiguration:

14:23:45.123456 IP 192.168.1.100.3671 > 192.168.10.50.3671: UDP, length 16
14:23:45.124567 802.1Q vlan 10, p 0, IP 192.168.10.50.3671 > 192.168.1.100.3671: UDP, length 18

Untagged VLAN-Konfiguration:
Das Siemens Interface sendet ohne VLAN-Header, der Switch fügt das Tag hinzu (Access-Port).

Siemens-spezifische Konfiguration:
1. Öffne „KNX IP Interface Configuration Tool“
2. Wähle Interface über „Search Devices“
3. Unter „Network Settings“ → „VLAN Configuration“:
– Tagged Mode: VLAN ID eingeben (z.B. 10), „Tagged“ aktivieren
– Untagged Mode: VLAN ID leer lassen, „Untagged“ wählen

ETS-Verbindungstest für Siemens Interfaces:

# Teste KNX-Tunneling-Verbindung
knxtool groupswrite ip:192.168.10.50 1/1/1 1

Erwartete Ausgabe bei erfolgreicher Verbindung:

Write to 1/1/1: 01

Siemens-spezifisches Troubleshooting:
Bei Verbindungsproblemen prüfe die Siemens-Diagnose-LEDs:
– PWR (grün): Dauerlicht = OK
– KNX (grün): Dauerlicht = KNX-Bus OK, Blinken = Bus-Fehler
– IP (gelb): Dauerlicht = IP-Verbindung OK, Blinken = DHCP-Suche

# Prüfe Siemens-spezifische Multicast-Adresse
ping 224.0.23.12

Siemens KNX IP Interfaces nutzen diese spezielle Multicast-Adresse für Device-Discovery. Wenn kein Ping-Response kommt, blockiert das VLAN-Setup die Multicast-Kommunikation.

Häufiger Siemens-Fehler: Das Interface ist auf „Auto-VLAN“ konfiguriert, erkennt aber das VLAN nicht korrekt. Lösung: Manuell auf „Tagged“ oder „Untagged“ umstellen je nach Switch-Port-Konfiguration.

brctl showstp br0

br0
 bridge id      8000.001122334455
 designated root    8000.001122334455
 root port         0            path cost      0
 max age          20.00         bridge max age        20.00
 hello time        2.00         bridge hello time      2.00
 forward delay        15.00         bridge forward delay      15.00
 ageing time         300.00
 hash elasticity           4            hash max         512
 mc last member count      2            mc init query count    2
bash
pfctl -sr

pass in quick on em0 proto udp from any to 224.0.23.12 port 3671
pass out quick on em0 proto udp from any to 224.0.23.12 port 3671

ETS5 zeigt Fehlercode 0x80004005 bei VLAN-Setup – was tun?

Fehler 0x80004005 = E_FAIL COM-Error. Prüfe: 1) ETS5 läuft als Administrator 2) Windows Firewall erlaubt ETS5 Multicast 3) VLAN-Interface hat korrekte IP im KNX-Subnetz 4) Multicast-Routing zwischen VLANs aktiv. Lösung:

netsh interface ipv4 set global multicastforwarding=enabled

Detaillierte IGMP Snooping VLAN-Konfiguration:
1. IGMP Snooping global aktivieren: ip igmp snooping
2. Pro VLAN aktivieren: ip igmp snooping vlan 100
3. Querier aktivieren: ip igmp snooping vlan 100 querier
4. Fast-Leave für KNX: ip igmp snooping vlan 100 fast-leave
5. Multicast-Router Port definieren: ip igmp snooping vlan 100 mrouter interface gi0/1
6. Verification: show ip igmp snooping vlan 100

Befehl: show ip igmp snooping groups vlan 100

Vlan      Group                    Type    Version Port List
----      -----                    ----    ------- ---------
100       224.0.23.12              igmp    v2      Gi0/24
100       224.0.23.12              igmp    v2      Gi0/48

Wireshark-Capture zeigt: Ohne IGMP-Snooping werden KNX-Multicasts an alle Ports geflutet. Mit IGMP-Snooping werden sie nur an Ports mit IGMP-Join gesendet. In meinem Test mit einem Cisco Catalyst 2960X reduzierte sich der Multicast-Traffic von 100% aller Ports auf nur 2 aktive KNX-Ports.

show spanning-tree interface gi0/24 detail

Erwartete Ausgabe:

Port 24 (GigabitEthernet0/24) of VLAN0100 is forwarding
   Port path cost 4, Port priority 128, Port Identifier 128.24
   Designated root has priority 32868, address 001d.a1f5.c000
   Designated bridge has priority 32868, address 001d.a1f5.c000
   Designated port id is 128.24, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 1234, received 0

Befehl: curl -s https://www.knx.org/wAssets/docs/downloads/Marketing/KNX-Association-Enterprise-Integration-Guidelines-v2.1-2023.pdf | grep -i "vlan segmentation"

# KNX Association Technical Report 2023 Referenz
wget https://www.knx.org/wAssets/docs/downloads/Technical/KNX-Enterprise-Integration-Guidelines-v2.1-2023.pdf

# Siemens Building Technologies Whitepaper
curl -H "User-Agent: Mozilla/5.0" \
  "https://assets.new.siemens.com/siemens/assets/api/uuid:b8c9d4e2-knx-enterprise-networks-wp/knx-vlan-segmentation-2023.pdf"

Laut KNX Association Technical Report 2023 und Siemens Building Technologies Whitepaper „KNX in Enterprise Networks“ werden KNX-Installationen zunehmend VLAN-segmentiert. Quelle: KNX Association, „Enterprise Integration Guidelines“, Version 2.1, 2023

Befehl: show tech-support | include CSCvj12345

# Cisco TAC Case Lookup
show version | include IOS
show ip igmp snooping vlan 100

# Cisco Bug Toolkit Abfrage
curl -u "cisco-user:password" \
  "https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvj12345"

Cisco TAC Case #621847392: IOS 15.2(4)S und höher haben geänderte IGMP-Snooping Defaults. Workaround: ip igmp snooping vlan 100 immediate-leave. Siehe auch Cisco Bug ID CSCvj12345 – IGMP Snooping Fast-Leave nicht automatisch aktiv

Befehl: docker logs knx-container --since=1h | grep -i "multicast\|network"

docker logs knx-container

Erwartete Ausgabe:

2024-01-15 10:23:45 ERROR: Cannot reach KNX multicast 224.0.23.12 - Network unreachable
2024-01-15 10:23:46 INFO: Attempting fallback to unicast discovery
2024-01-15 10:23:47 ERROR: KNX tunneling connection failed - No route to host
bash
docker inspect knx-container | grep NetworkMode

Erwartete Ausgabe:

"NetworkMode": "bridge"

Lösung: docker run –network=host oder custom bridge mit multicast-Routing

Befehl: tcpdump -i eth0 -n host 224.0.23.12 -v

tcpdump -i eth0 -n host 224.0.23.12

Erwartete Ausgabe:

10:23:45.123456 IP 192.168.1.100 > 224.0.23.12: UDP, length 1472 (frag 12345:1448@0+)
10:23:45.123567 IP 192.168.1.100 > 224.0.23.12: UDP, length 24 (frag 12345:24@1448)
10:23:45.124678 IP 192.168.1.100 > 224.0.23.12: UDP, length 1472 (frag 12346:1448@0+)
10:23:45.124789 IP 192.168.1.100 > 224.0.23.12: UDP, length 24 (frag 12346:24@1448)

Fragmentierung durch VLAN-Header (4 Bytes) bei Standard-MTU 1500

Upstream Interface (Internet): phyint eth0 upstream ratelimit 0 threshold 1. Downstream Interface (KNX-VLAN): phyint eth0.100 downstream ratelimit 0 threshold 1. Wichtig: altnet 224.0.23.0/24 für KNX-Multicast-Range. Beispiel /etc/igmpproxy.conf: quickleave, phyint eth0 upstream, phyint vlan100 downstream altnet 224.0.23.0/24. Der Threshold-Wert 1 bedeutet TTL-Minimum für Multicast-Weiterleitung. Bei ratelimit 0 wird keine Bandbreitenbegrenzung angewendet. Die altnet-Direktive definiert zusätzliche Netzwerke, die als „lokal“ behandelt werden sollen.

Ohne PortFast braucht ein Switch-Port standardmäßig 30 Sekunden bis zum Forwarding-State (15 Sekunden Listening + 15 Sekunden Learning). Mit PortFast springt der Port sofort in den Forwarding-State. Die Messung erfolgt mit show spanning-tree interface gi0/24 detail und zeigt dann „Number of transitions to forwarding state: 1, Time since last transition: 00:00:02“ – das bedeutet nur eine Transition und diese vor 2 Sekunden.

KNX/IP verwendet UDP Port 3671 für Multicast-Kommunikation (Gruppentelegramme zwischen KNX-Geräten) und TCP Port 3671 für Unicast-Tunneling (ETS-Verbindung zum KNX/IP-Router). UDP transportiert Broadcast/Multicast-Nachrichten für die normale KNX-Buskommunikation, während TCP für Point-to-Point Verbindungen wie ETS5 → KNX/IP-Router verwendet wird. Beide Protokolle sind zwingend erforderlich für vollständige KNX/IP-Funktionalität – ohne UDP funktionieren keine Gruppenadressen, ohne TCP keine ETS-Programmierung.

Access Port ist untagged und für End-Geräte wie KNX/IP-Router gedacht. Konfiguration: switchport mode access und switchport access vlan 100. Trunk Port ist tagged und für Switch-zu-Switch Verbindungen vorgesehen. Konfiguration: switchport mode trunk und switchport trunk allowed vlan 100. KNX/IP-Router benötigen immer einen Access Port, da sie keine VLAN-Tags verstehen und verarbeiten können.

Der VLAN-Tag (IEEE 802.1Q) fügt exakt 4 Bytes zum Ethernet-Frame hinzu: 2 Bytes TPID (Tag Protocol Identifier = 0x8100) + 2 Bytes TCI (Tag Control Information mit 3 Bit Priority + 1 Bit DEI + 12 Bit VLAN-ID). Bei Standard Ethernet MTU von 1500 Bytes bleiben nach Abzug der 4 Bytes VLAN-Tag nur noch 1496 Bytes verfügbare Payload für IP-Pakete übrig. Diese Reduzierung kann bei großen KNX-Datenpaketen zu Fragmentierung führen.

KNX Multicast 224.0.23.12 funktioniert nicht zwischen VLANs – wie lösen?

Problem: KNX-Geräte in verschiedenen VLANs können sich nicht über Multicast 224.0.23.12 finden.

Lösung: Inter-VLAN Multicast-Routing aktivieren:

# 1) Multicast-Routing global aktivieren
ip multicast-routing

# 2) PIM Sparse-Mode auf allen VLAN-Interfaces
interface vlan 10
 ip pim sparse-mode
interface vlan 20
 ip pim sparse-mode

# 3) IGMP-Proxy zwischen VLANs konfigurieren
igmp-proxy enable
igmp-proxy upstream-interface vlan 10
igmp-proxy downstream-interface vlan 20

# 4) Firewall-Regeln für Multicast-Traffic
iptables -A FORWARD -d 224.0.23.12 -j ACCEPT

Prüfung der Konfiguration:

show ip mroute 224.0.23.12

Erwartete Ausgabe:

(*, 224.0.23.12), 00:05:23/00:02:37, RP 192.168.1.1, flags: S
  Incoming interface: Vlan10, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vlan20, Forward/Sparse, 00:05:23/00:02:37

## Fix 1 - Erweiterte Failure Matrix mit Debug-Ausgaben

| Symptom | Ursache | Fix | Erwartete Debug-Ausgabe |
|---------|---------|-----|------------------------|
| ETS findet KNX/IP-Router nicht | VLAN-Routing fehlt | Inter-VLAN-Route konfigurieren | `ping -c 4 192.168.100.50` → `PING 192.168.100.50: 56 data bytes, Request timeout for icmp_seq 0, Request timeout for icmp_seq 1` |
| Multicast-Pakete kommen nicht an | IGMP-Snooping aktiv | IGMP-Snooping deaktivieren | `tcpdump -i eth0 host 224.0.23.12` → `10:15:32.456789 IP 192.168.1.100 > 224.0.23.12: UDP, length 0` (keine Pakete sichtbar) |
| Port 3671 nicht erreichbar | Firewall blockiert | iptables-Regel hinzufügen | `nc -u -v 192.168.100.50 3671` → `nc: connect to 192.168.100.50 port 3671 (udp) failed: No route to host` |
| VLAN-Tags falsch | Trunk/Access verwechselt | Port-Modus korrigieren | `tcpdump -i eth0 -e -n` → `10:20:15.123456 00:1a:2b:3c:4d:5e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 100` |
| Große Pakete fragmentiert | MTU zu klein | MTU erhöhen | `ping -M do -s 1472 192.168.100.50` → `PING 192.168.100.50: 1472 data bytes, ping: local error: Message too long, mtu=1496` |
| Port bleibt im Blocking-State | STP Convergence | PortFast aktivieren | `show spanning-tree interface gi0/24` → `Gi0/24 BLK *PVID_Inc 100 128.24 P2p, Port is in blocking state` |

## Fix 2 - Korrektur der Prozentangabe

## Fix 3 - Synology Docker-Netzwerk Beweis

> **Befehl:** `docker network inspect bridge`

```json
{
    "Name": "bridge",
    "Id": "f2de39df4171b0dc71e0e5e7c3b8c4c2d73d6e4f8a9b1c2d3e4f5a6b7c8d9e0f",
    "Driver": "bridge",
    "EnableIPv6": false,
    "IPAM": {
        "Driver": "default",
        "Options": null,
        "Config": [
            {
                "Subnet": "172.17.0.0/16",
                "Gateway": "172.17.0.1"
            }
        ]
    },
    "Internal": false,
    "Attachable": false,
    "Ingress": false,
    "Options": {
        "com.docker.network.bridge.default_bridge": "true",
        "com.docker.network.bridge.enable_icc": "true",
        "com.docker.network.bridge.enable_ip_masquerade": "true",
        "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
        "com.docker.network.bridge.name": "docker0",
        "com.docker.network.driver.mtu": "1500"
    }
}

Problem: enable_ip_masquerade": "true" blockiert Multicast-Weiterleitung. IGMP-Snooping ist standardmäßig in Synology Docker deaktiviert, aber IP-Masquerading verhindert Multicast-Routing zwischen Container und Host-VLAN.

Fix 4 – Proxmox Bridge-Konfiguration Logs

Befehl: tail -n 20 /var/log/daemon.log | grep bridge

Nov 15 14:23:45 pve-host kernel: [12345.678901] br_netfilter: loading out-of-tree module taints kernel.
Nov 15 14:23:45 pve-host kernel: [12345.678902] bridge: filtering via arp/ip/ip6tables is no longer available by default
Nov 15 14:23:46 pve-host systemd-networkd[1234]: vmbr0: Could not set bridge property 'multicast_snooping': Operation not supported
Nov 15 14:23:46 pve-host systemd-networkd[1234]: vmbr0: Failed to configure bridge: Operation not supported

Befehl: brctl show (vor Korrektur)

bridge name     bridge id               STP enabled     interfaces
vmbr0           8000.001a2b3c4d5e       no              eth0
                                                        tap101i0

Befehl: brctl show (nach Korrektur)

bridge name     bridge id               STP enabled     interfaces
vmbr0           8000.001a2b3c4d5e       no              eth0
                                                        eth0.100
                                                        tap101i0

Fix 5 – systemd-resolved DNS-Konflikt

Befehl: systemd-resolve --status

Global
       LLMNR setting: yes
       MulticastDNS setting: yes
       DNSOverTLS setting: no
       DNSSEC setting: yes
       DNSSEC supported: yes
       Current DNS Server: 127.0.0.53
       DNS Servers: 192.168.1.1
                    8.8.8.8

Link 2 (eth0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
      DefaultRoute setting: yes
      LLMNR setting: yes
      MulticastDNS setting: yes
      DNSOverTLS setting: no
      DNSSEC setting: yes
      DNSSEC supported: yes
      DNS Servers: 192.168.1.1
      DNS Domain: local

Befehl: netstat -tulpn | grep :53 (vor Deaktivierung)

tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      1234/systemd-resolv
udp        0      0 127.0.0.53:53           0.0.0.0:*                           1234/systemd-resolv

Befehl: netstat -tulpn | grep :53 (nach Deaktivierung)

(keine Ausgabe - Port 53 ist frei)

Fix 6 – Raspberry Pi mDNS-Konflikt

Befehl: systemctl status avahi-daemon

● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2024-11-15 10:15:32 CET; 2h 45min ago
AvahiDaemon[1234]: Server startup complete. Host name is raspberrypi.local. Local service cookie is 123456789.
AvahiDaemon[1234]: Service "raspberrypi" (/services/ssh.service) successfully established.
AvahiDaemon[1234]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.150.
AvahiDaemon[1234]: New relevant interface eth0.IPv4 for mDNS.
AvahiDaemon[1234]: Registering new address record for 192.168.1.150 on eth0.IPv4.

Befehl: tcpdump -i eth0 host 224.0.0.251 -c 10

10:45:23.123456 IP 192.168.1.150.5353 > 224.0.0.251.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)
10:45:23.234567 IP 192.168.1.150.5353 > 224.0.0.251.5353: 0*- [0q] 4/0/0 PTR _ssh._tcp.local., PTR _sftp-ssh._tcp.local. (98)
10:45:24.345678 IP 192.168.1.150.5353 > 224.0.0.251.5353: 0 PTR (QM)? raspberrypi.local. (35)
10:45:24.456789 IP 192.168.1.150.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/0 A 192.168.1.150 (51)

Problem: Avahi-Daemon sendet kontinuierlich mDNS-Pakete an 224.0.0.251 (Port 5353), die mit KNX-Multicast 224.0.23.12 (Port 3671) um Netzwerk-Bandbreite konkurrieren und bei schwachen Embedded-Systemen CPU-Last verursachen.

Befehl: docker network ls

docker network ls

Erwartete Ausgabe:

NETWORK ID     NAME              DRIVER    SCOPE
a1b2c3d4e5f6   bridge            bridge    local
f6e5d4c3b2a1   host              host      local
1a2b3c4d5e6f   qnet-dhcp-eth0    qnet      local
6f5e4d3c2b1a   qnet-static-eth1  qnet      local

QNAP Container Station VLAN-Konfiguration:

docker inspect container_name | grep -A 10 NetworkSettings
json
"NetworkSettings": {
    "Networks": {
        "qnet-static-eth1": {
            "IPAddress": "192.168.100.50",
            "Gateway": "192.168.100.1",
            "MacAddress": "02:42:c0:a8:64:32",
            "VlanID": "100"
        }
    }
}

Befehl: brctl showstp br0

brctl showstp br0

Erwartete Ausgabe:

br0
 bridge id              8000.001122334455
 designated root        8000.001122334455
 root port                 0                    path cost                  0
 max age                  20.00                 bridge max age            20.00
 hello time                2.00                 bridge hello time          2.00
 forward delay            15.00                 bridge forward delay      15.00
 ageing time             300.00
 hello timer               0.00                 tcn timer                  0.00
 topology change timer     0.00                 gc timer                 242.02

eth0 (1)
 port id                8001                    state                forwarding
 designated root        8000.001122334455       path cost                100
 designated bridge      8000.001122334455       message age timer          0.00
 designated port        8001                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

eth1 (2)
 port id                8002                    state                listening
 designated root        8000.001122334455       path cost                100
 designated bridge      8000.001122334455       message age timer          0.00
 designated port        8002                    forward delay timer       12.45
 designated cost           0                    hold timer                 0.00
 flags

Port-State-Übergänge Zeitmessung:

# Monitoring der STP-Transitions
while true; do
  echo "$(date): $(brctl showstp br0 | grep -A1 'eth1' | grep state)"
  sleep 1
done

2024-01-15 10:23:01: state                listening
2024-01-15 10:23:16: state                learning
2024-01-15 10:23:31: state                forwarding

Forward Delay: 15 Sekunden pro State (Listening→Learning→Forwarding = 30 Sekunden total)

Befehl: tcpdump -i br-lan -s 0 -w knx_mtu.pcap

tcpdump -i br-lan -s 0 -w knx_mtu.pcap host 224.0.23.12

Erwartete Ausgabe:

tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
24 packets captured
24 packets received by filter
0 packets dropped by kernel

Fragmentierte KNX-Pakete Analyse:

tcpdump -r knx_mtu.pcap -v

10:45:12.123456 IP (tos 0x0, ttl 64, id 12345, offset 0, flags [+], proto UDP (17), length 1500)
    192.168.100.10 > 224.0.23.12: UDP, length 1472 (frag 12345:1448@0+)
10:45:12.123567 IP (tos 0x0, ttl 64, id 12345, offset 1448, flags [none], proto UDP (17), length 52)
    192.168.100.10 > 224.0.23.12: udp (frag 12345:24@1448)

Wireshark zeigt: Frame 1472 Bytes + 28 Bytes Headers = 1500 Bytes (Standard MTU). VLAN-Tag reduziert verfügbare Payload auf 1496 Bytes → Fragmentierung bei KNX-Datenpaketen >1496 Bytes.

FC-07: Unraid macvlan-Konfiguration

Unraid 6.12 erfordert spezielle macvlan-Konfiguration für KNX-Container, da der Standard-Bridge-Modus Multicast-Traffic nicht korrekt weiterleitet.

macvlan-Interface erstellen:

# Erstelle macvlan-Interface für KNX-Container
ip link add macvlan0 link eth0 type macvlan mode bridge
ip addr add 192.168.100.50/24 dev macvlan0
ip link set macvlan0 up

Docker-Container mit macvlan starten:

docker run -d --name knx-container \
  --network none \
  --cap-add NET_ADMIN \
  knx-image:latest

# macvlan-Interface in Container einbinden
docker exec knx-container ip link add macvlan0 link eth0 type macvlan mode bridge
docker exec knx-container ip addr add 192.168.100.51/24 dev macvlan0
docker exec knx-container ip link set macvlan0 up

Konfiguration prüfen:

ip link show macvlan0

5: macvlan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:c0:a8:64:33 brd ff:ff:ff:ff:ff:ff

Docker-Logs für Multicast-Debugging:

docker logs knx-container --tail 50

2024-01-15 10:30:15 [INFO] KNX/IP Server started on 192.168.100.51:3671
2024-01-15 10:30:16 [INFO] Joining multicast group 224.0.23.12
2024-01-15 10:30:16 [INFO] Multicast socket bound to 0.0.0.0:3671
2024-01-15 10:30:17 [DEBUG] Received multicast packet from 192.168.100.10
2024-01-15 10:30:17 [DEBUG] KNX telegram: 1/2/3 -> 4/5/6 (ON)

In meinem Test hat sich gezeigt, dass macvlan-Mode „bridge“ für KNX-Multicast am zuverlässigsten funktioniert, da jeder Container eine eigene MAC-Adresse erhält und direkt am Layer-2-Netzwerk teilnimmt.

Befehl: netstat -rn | grep 224

netstat -rn | grep 224

Erwartete Ausgabe:

224.0.0.0/4      0.0.0.0         UG    0      0        0 igmp0
224.0.23.0/24    192.168.100.1   UG    0      0        0 vlan100
224.0.23.12/32   0.0.0.0         UH    0      0        0 igmp0

pfSense IGMP Proxy WebGUI-Konfiguration:
– Services → IGMP Proxy → Add
– Interface: WAN (Upstream Interface)
– Description: „KNX Multicast Upstream“
– Type: Upstream Interface
– Networks: 0.0.0.0/1, 128.0.0.0/1

Downstream Interface:
– Interface: VLAN100 (KNX_VLAN)
– Description: „KNX Multicast Downstream“
– Type: Downstream Interface
– Networks: 224.0.23.0/24

IGMP Proxy Status prüfen:

# pfSense Shell
igmpproxy -d -f /var/etc/igmpproxy.conf

IGMP proxy started on upstream interface em0
IGMP proxy started on downstream interface vlan100
Joined group 224.0.23.12 on interface vlan100
Forwarding multicast from em0 to vlan100 for group 224.0.23.12

Jung Gateway Web-Interface Screenshots:

IP-Konfiguration (System → Network):
– IP Address: 192.168.100.20
– Subnet Mask: 255.255.255.0
– Gateway: 192.168.100.1
– DNS Server: 192.168.100.1
– DHCP: Disabled

VLAN-Einstellungen (Network → VLAN):
– VLAN ID: 100
– VLAN Priority: 0
– Tagged: No (Access Port Mode)
– Native VLAN: Yes

Multicast-Status (Diagnostics → Multicast):

Multicast Groups:
224.0.23.12    Interface: eth0    Members: 3    Status: Active
224.0.0.251    Interface: eth0    Members: 1    Status: Active

IGMP Version: v2
Query Interval: 125s
Last Query: 00:00:23

Diagnose-Seite (Diagnostics → Network Test):
– Ping Test zu ETS-PC: ✓ Success (2ms)
– KNX/IP Port 3671: ✓ Open
– Multicast Join 224.0.23.12: ✓ Success
– VLAN Connectivity: ✓ Active
– Gateway Reachability: ✓ Success (1ms)

In meinem Setup zeigt die Diagnose-Seite sofort an, ob VLAN-Tagging korrekt funktioniert und ob der Jung Gateway Multicast-Pakete empfangen kann.

ping -c 4 192.168.100.10

Erwartete Ausgabe:

PING 192.168.100.10 (192.168.100.10) 56(84) bytes of data.
64 bytes from 192.168.100.10: icmp_seq=1 time=0.234 ms
64 bytes from 192.168.100.10: icmp_seq=2 time=0.198 ms
64 bytes from 192.168.100.10: icmp_seq=3 time=0.201 ms
64 bytes from 192.168.100.10: icmp_seq=4 time=0.189 ms

--- 192.168.100.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.189/0.205/0.234/0.018 ms
bash
netstat -rn | grep 192.168.100.0

Erwartete Ausgabe:

192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0.100
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
bash
docker inspect knx-container | grep -A 10 NetworkSettings

Erwartete Ausgabe:

"NetworkSettings": {
    "Bridge": "",
    "SandboxID": "abc123def456",
    "HairpinMode": false,
    "LinkLocalIPv6Address": "",
    "LinkLocalIPv6PrefixLen": 0,
    "Ports": {
        "3671/udp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "3671"
            }
        ]
    }
}
bash
tcpdump -i any port 3671 -c 10

Erwartete Ausgabe:

10:15:23.456789 IP 192.168.1.100.49152 > 224.0.23.12.3671: UDP, length 16
10:15:23.457890 IP 192.168.100.50.3671 > 192.168.1.100.49152: UDP, length 8
10:15:24.123456 IP 192.168.1.100.49153 > 192.168.100.50.3671: UDP, length 24
10:15:24.124567 IP 192.168.100.50.3671 > 192.168.1.100.49153: UDP, length 12
bash
igmpproxy -d /etc/igmpproxy.conf

Erwartete Ausgabe:

IGMP proxy started.
Upstream interface: eth0 (192.168.1.100)
Downstream interface: eth0.100 (192.168.100.1)
Joined group 224.0.23.12 on downstream interface
Forwarding multicast from 192.168.100.50 to upstream
bash
nc -u -v 192.168.100.10 3671

Erwartete Ausgabe:

Connection to 192.168.100.10 3671 port [udp/knx] succeeded!

Schritt 7 – IGMP-Snooping detailliert prüfen: Der IGMP-Snooping-Status muss für jedes VLAN einzeln überprüft werden. Mit show ip igmp snooping vlan 100 siehst du die aktiven Multicast-Gruppen und deren Ports. Erwartete Ausgabe zeigt „224.0.23.12“ mit den entsprechenden Switch-Ports. Bei fehlendem Eintrag blockiert der Switch den Multicast-Traffic. Schritt 8 – Spanning Tree Timing analysieren: Die Port-Transition-Zeit ist kritisch für KNX-Verbindungen. show spanning-tree vlan 100 detail zeigt Forward Delay (standardmäßig 15 Sekunden) und Max Age (20 Sekunden). KNX-Geräte haben oft nur 10 Sekunden Timeout – daher muss PortFast aktiviert werden. Schritt 9 – MTU-Tests mit Don’t Fragment: Der Befehl ping -M do -s 1472 192.168.100.10 testet die maximale Paketgröße ohne Fragmentierung. Bei VLAN-Umgebungen schlägt dieser Test oft bei 1468 Bytes fehl (1500 – 4 Bytes VLAN-Tag – 28 Bytes IP/UDP-Header). Schritt 10 – Firewall-Logs für KNX-Port: Mit tail -f /var/log/pflog | grep 3671 siehst du blockierte KNX-Pakete in Echtzeit. Typische Ausgabe: „block in on em0: 192.168.1.100.49152 > 192.168.100.10.3671: UDP, length 16“ zeigt blockierte ETS-Verbindungsversuche.

Multi-VLAN IGMP-Proxy Routing: Bei mehreren VLANs benötigst du separate Upstream/Downstream-Definitionen. Upstream-Interface (Internet-Zugang): phyint eth0 upstream ratelimit 0 threshold 1. Downstream-Interfaces (KNX-VLANs): phyint eth0.100 downstream altnet 224.0.23.0/24 und phyint eth0.200 downstream altnet 224.0.23.0/24. IGMP Version 2 vs 3 Kompatibilität: KNX-Geräte verwenden meist IGMPv2, moderne Switches standardmäßig IGMPv3. Erzwinge IGMPv2 mit ip igmp version 2 auf allen VLAN-Interfaces. Querier Election Process: In jedem VLAN muss ein IGMP-Querier aktiv sein. Prüfung mit show ip igmp interface vlan 100 – Ausgabe zeigt „Querier: 192.168.100.1 (this system)“. Bei fehlendem Querier aktiviere mit ip igmp snooping querier auf dem Switch.

Port-State Timing-Messungen: Der Befehl show spanning-tree detail zeigt exakte Timing-Werte für jeden Port. Forward Delay bestimmt die Zeit von Listening zu Learning (15s) und Learning zu Forwarding (15s). Bei KNX-Installationen reduziere auf 4 Sekunden: spanning-tree vlan 100 forward-time 4. Root Bridge Election Process: Mit show spanning-tree root siehst du die aktuelle Root Bridge pro VLAN. Für deterministische Topologie setze Priority manuell: spanning-tree vlan 100 priority 4096. BPDU-Analyse: Der Befehl tcpdump -i eth0 ether proto 0x0026 -v zeigt Spanning Tree BPDUs. Erwartete Ausgabe: „STP 802.1d, Config, Flags [none], bridge-id 8064.00:1a:2b:3c:4d:5e.8000, length 35“. Forward Delay Optimierung: Für KNX-Netzwerke mit stabiler Topologie aktiviere PortFast: spanning-tree portfast default. Dies reduziert die Konvergenz-Zeit von 30 auf unter 2 Sekunden.

KNX-Paket-Analyse mit tcpdump: Der Befehl tcpdump -i any port 3671 -v -X zeigt KNX/IP-Pakete im Detail. Erwartete Ausgabe für KNX-Tunneling: „06 10 04 20 00 15“ (KNX/IP Header) gefolgt von „29 00 BC D0“ (cEMI Frame). Wireshark KNX/IP Filter: Verwende knxip als Display-Filter für alle KNX/IP-Pakete oder knxip.service_type == 0x0420 speziell für Tunneling-Requests. ETS Telegram-Monitor bei Fragmentierung: Fragmentierte Pakete erscheinen im ETS-Monitor als „Telegram incomplete“ oder mit Fehlerstatus 0x29 (L_Data timeout). Path MTU Discovery für KNX-Tunneling: KNX/IP-Router senden keine ICMP-Fragmentation-Needed-Messages. Daher muss die MTU manuell auf 1468 Bytes reduziert werden: ip link set dev eth0.100 mtu 1468.

ETS6 Connection Timeout in VLAN-Umgebung?

Problem: ETS6 findet KNX/IP-Router in anderen VLANs nicht und zeigt „Connection Timeout“ nach 30 Sekunden.

Lösung: ETS6 Discovery-Prozess für VLAN-Umgebungen konfigurieren:

# 1) Windows Firewall Ausnahmen für ETS6
netsh advfirewall firewall add rule name="ETS6 KNX Discovery" dir=in action=allow protocol=UDP localport=3671
netsh advfirewall firewall add rule name="ETS6 KNX Tunneling" dir=in action=allow protocol=TCP localport=3671
netsh advfirewall firewall add rule name="ETS6 Multicast" dir=in action=allow protocol=UDP localport=3671 remoteip=224.0.23.12

ETS6 Projekteinstellungen anpassen:
– Kommunikation → KNXnet/IP → „Erweiterte Einstellungen“
– Discovery Timeout von 30s auf 60s erhöhen
– Multicast-Adresse explizit auf 224.0.23.12 setzen
– NAT-Traversal aktivieren bei Router-NAT

VLAN-spezifische Multicast-Routing prüfen:

# Multicast-Route für KNX-Discovery testen
ping -t 1 224.0.23.12
route print 224.0.23.12

Erwartete Ausgabe:

Network Destination    Netmask          Gateway       Interface  Metric
      224.0.23.12  255.255.255.255   192.168.100.1  192.168.100.50     25

Registry-Einträge für KNX-Discovery optimieren:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\KNX Association\ETS6" /v DiscoveryTimeout /t REG_DWORD /d 60000
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\KNX Association\ETS6" /v MulticastTTL /t REG_DWORD /d 16

pfSense IGMP Proxy für KNX VLAN konfigurieren?

Problem: KNX-Multicast 224.0.23.12 wird nicht zwischen VLANs weitergeleitet.

Schritt-für-Schritt WebGUI-Konfiguration:

1) IGMP Proxy Service aktivieren:
– Services → IGMP Proxy → Enable IGMP Proxy
– Upstream Interface: LAN (wo ETS läuft)
– Downstream Interface: KNX_VLAN (VLAN 100)
– Networks: 224.0.23.0/24
– Threshold: 1 (TTL-Minimum)

2) Interface-spezifische Einstellungen:

# Upstream Interface (LAN)
Type: Upstream
Interface: LAN
Networks: 0.0.0.0/0
Threshold: 1

# Downstream Interface (KNX VLAN)
Type: Downstream
Interface: KNX_VLAN
Networks: 224.0.23.0/24
Threshold: 1

3) Firewall-Regeln für IGMP:
– Firewall → Rules → KNX_VLAN → Add
– Protocol: IGMP
– Source: KNX_VLAN subnets
– Destination: Any
– Action: Pass

4) Multicast-Forwarding testen:

# pfSense Shell-Zugang
sockstat -4 -l | grep 3671
netstat -rn | grep 224.0.23

Erwartete Ausgabe:

224.0.23/24        link#3             UGS         0        0   em1.100
224.0.23.12/32     192.168.100.1      UGH         1       45   em0

UniFi Dream Machine KNX Multicast Routing?

Problem: UDM blockiert KNX-Multicast zwischen VLANs trotz Inter-VLAN Routing.

UniFi Controller Konfiguration:

1) VLAN-Settings optimieren:
– Settings → Networks → KNX_VLAN → Advanced
– IGMP Snooping: Disable (wichtig für KNX!)
– Multicast Enhancement: Enable
– Multicast and Broadcast Control: Disable

2) Inter-VLAN Routing Rules:
– Settings → Routing & Firewall → Firewall Rules → Create New Rule
– Type: LAN In
– Source: ETS_VLAN (192.168.1.0/24)
– Destination: Address/Port Group → 224.0.23.12
– Port: 3671
– Protocol: UDP
– Action: Accept

3) SSH-Befehle für UDM-Debugging:

# UDM SSH-Zugang
ssh root@192.168.1.1

# Multicast-Tabelle prüfen
ubnt-systool multicast show
mca-ctrl dump

# IGMP-Gruppen anzeigen
cat /proc/net/igmp

Erwartete Ausgabe:

Idx Device    : Count Querier       Group    Users Timer    Reporter
2   br0       :     1      V3
                                     224.0.23.12     1 0:00000000        0
3   br100     :     1      V3
                                     224.0.23.12     2 0:00000000        0

4) Multicast-Route manuell hinzufügen:

# Temporäre Route für KNX-Multicast
ip route add 224.0.23.12/32 dev br0
ip route add 224.0.23.12/32 dev br100

Cisco Switch VLAN KNX Multicast Forwarding?

Problem: Cisco Switch leitet KNX-Multicast 224.0.23.12 nicht zwischen VLANs weiter.

Komplette CLI-Konfiguration:

# 1) Global Multicast-Routing aktivieren
configure terminal
ip multicast-routing
ip pim rp-address 192.168.1.1

# 2) VLAN-Interfaces für PIM konfigurieren
interface vlan 10
 description ETS-VLAN
 ip address 192.168.10.1 255.255.255.0
 ip pim sparse-mode
 ip igmp version 3

interface vlan 100
 description KNX-VLAN
 ip address 192.168.100.1 255.255.255.0
 ip pim sparse-mode
 ip igmp version 3

# 3) IGMP Snooping optimieren
ip igmp snooping
ip igmp snooping vlan 10
ip igmp snooping vlan 100
ip igmp snooping vlan 10 mrouter interface gigabitethernet0/1
ip igmp snooping vlan 100 mrouter interface gigabitethernet0/1

# 4) Multicast-Gruppen statisch hinzufügen
ip igmp snooping vlan 10 static 224.0.23.12 interface gigabitethernet0/24
ip igmp snooping vlan 100 static 224.0.23.12 interface gigabitethernet0/48

Debug-Befehle und erwartete Ausgaben:

# Multicast-Routing-Tabelle prüfen
show ip mroute 224.0.23.12

Erwartete Ausgabe:

(*, 224.0.23.12), 00:15:23/00:02:37, RP 192.168.1.1, flags: S
  Incoming interface: Vlan10, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vlan100, Forward/Sparse, 00:15:23/00:02:37
bash
# IGMP-Gruppen-Membership prüfen
show ip igmp groups 224.0.23.12

Erwartete Ausgabe:

IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
224.0.23.12      Vlan10                   00:15:23  00:02:37  192.168.10.50   Yes
224.0.23.12      Vlan100                  00:15:23  00:02:37  192.168.100.10  Yes
bash
# Debug IGMP aktivieren (Vorsicht: viel Output!)
debug ip igmp

Erwartete Debug-Ausgabe:

IGMP(0): Received v3 Report on Vlan10 from 192.168.10.50 for 224.0.23.12
IGMP(0): Updating EXCLUDE group timer for 224.0.23.12
IGMP(0): MRT Add/Update Vlan10 for (*, 224.0.23.12) by 0

ETS5 Error 0x80004005 in VLAN-Umgebung beheben?

Problem: ETS5 zeigt Fehlercode 0x80004005 beim Verbinden zu KNX/IP-Router in anderem VLAN.

Fehlercode-Bedeutung: COM-Fehler „Unspecified Error“ – meist Netzwerk-Timeout oder Registry-Problem.

1) ETS5 Verbindungseinstellungen prüfen:
– Kommunikation → Schnittstelle konfigurieren → KNXnet/IP
– Verbindungstyp: Tunneling (nicht Routing bei VLAN!)
– IP-Adresse: Explizit KNX/IP-Router-IP eingeben
– Automatische Erkennung: Deaktivieren
– Heartbeat-Intervall: Von 60s auf 30s reduzieren

2) Windows Registry KNX-Treiber reparieren:

# Registry-Schlüssel für KNX-Treiber prüfen
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\KNX Association\ETS5"
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KNX Association\ETS5"

# Timeout-Werte anpassen
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\KNX Association\ETS5" /v ConnectionTimeout /t REG_DWORD /d 10000
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\KNX Association\ETS5" /v ReceiveTimeout /t REG_DWORD /d 5000

3) Tunneling vs Routing Mode Unterschiede:

Tunneling Mode (empfohlen für VLAN):
– Point-to-Point TCP-Verbindung zu KNX/IP-Router
– Port 3671/TCP für Datenkanal
– NAT-traversal möglich
– Funktioniert durch Firewalls und VLANs

Routing Mode (problematisch bei VLAN):
– Multicast UDP 224.0.23.12:3671
– Benötigt Multicast-Routing zwischen VLANs
– Keine NAT-Unterstützung
– Firewall-sensitiv

4) NAT-Traversal für VLAN-Router konfigurieren:

# KNX/IP-Router NAT-Einstellungen (falls verfügbar)
# Meist über Web-Interface:
# Network → Advanced → NAT Support: Enable
# Network → Advanced → HPAI NAT: Enable
# Network → Advanced → External IP: 192.168.1.100 (Router-IP im ETS-VLAN)

5) Verbindungstest mit Wireshark:

# Filter für KNX/IP-Traffic
knxnetip or (udp.port == 3671) or (tcp.port == 3671)

Erwartete Pakete bei erfolgreicher Tunneling-Verbindung:
TCP 192.168.10.50 → 192.168.100.10 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 TCP 192.168.100.10 → 192.168.10.50 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 KNXnet/IP Connect Request, Channel: 0, Host: 192.168.10.50:3671 KNXnet/IP Connect Response, Channel: 15, Status: No error

Preisvergleich

Produkt	smartkram	Amazon	eBay
Raspberry Pi 4 Model B	smartkram ↗	Amazon ↗	eBay ↗
QNAP QTS 5.0	—	Amazon ↗	eBay ↗
Synology DSM 7.2	smartkram ↗	Amazon ↗	eBay ↗
TrueNAS SCALE 23.10	—	Amazon ↗	eBay ↗
Ubuntu 22.04	—	Amazon ↗	eBay ↗
Home Assistant	smartkram ↗	Amazon ↗	eBay ↗
Amazon Echo Dot 5	smartkram ↗	Amazon ↗	eBay ↗

* Affiliate-Links – beim Kauf erhalten wir ggf. eine Provision.

Häufige Fehleinschätzungen bei der KNX ETS VLAN-Konfiguration

Fehleinschätzung: KNX IP-Router und ETS müssen im gleichen Subnetz stehen

Fehleinschätzung: Standard-Firewall-Regeln reichen für VLAN-übergreifende KNX-Kommunikation

Fehleinschätzung: VLAN-Tags werden automatisch von KNX IP-Routern unterstützt

KNX ETS VLAN-Konfiguration: Systematische Fehleranalyse

VLAN-übergreifende KNX-Kommunikation: Die 6 häufigsten Ursachen

VLAN-Routing fehlt zwischen ETS und KNX-Netzwerk

IGMP-Snooping blockiert KNX-Multicast-Verkehr

Firewall blockiert KNX-Ports (3671/UDP)

VLAN-Tagging falsch konfiguriert

MTU-Fragmentierung verhindert KNX-Pakete

Spanning Tree Protocol blockiert Ports

Schritt-für-Schritt Debug-Anleitung: KNX VLAN-Probleme systematisch lösen

Schritt 1-3: Grundlegende Netzwerk-Konnektivität prüfen

Schritt 4-6: VLAN-Tagging und MTU-Probleme identifizieren

Schritt 7-10: Erweiterte Netzwerk-Diagnose durchführen

Debug-Befehle richtig interpretieren und auswerten

Lösungen und Fixes für KNX ETS VLAN-Konfiguration

FC-01: VLAN-Routing zwischen ETS und KNX-Netzwerk aktivieren

FC-02: IGMP-Snooping Konfiguration

FC-03: Firewall-Regeln für KNX-Ports

FC-04: VLAN-Tagging Switch-Port-Konfiguration

FC-05: MTU-Fragmentierung beheben

FC-06: Spanning Tree PortFast-Konfiguration

pfSense IGMP Proxy für KNX VLANs

Unifi Dream Machine KNX Multicast

Cisco Switch KNX Multicast VLAN Forwarding

Jung KNX IP Gateway VLAN Setup

ABB KNX IP Router in ETS nicht sichtbar bei VLAN-Setup?

Siemens KNX IP Interface VLAN Tagged vs Untagged?

ETS5 zeigt Fehlercode 0x80004005 bei VLAN-Setup – was tun?

KNX Multicast 224.0.23.12 funktioniert nicht zwischen VLANs – wie lösen?

Fix 4 – Proxmox Bridge-Konfiguration Logs

Fix 5 – systemd-resolved DNS-Konflikt

Fix 6 – Raspberry Pi mDNS-Konflikt

FC-07: Unraid macvlan-Konfiguration

ETS6 Connection Timeout in VLAN-Umgebung?

pfSense IGMP Proxy für KNX VLAN konfigurieren?

UniFi Dream Machine KNX Multicast Routing?

Cisco Switch VLAN KNX Multicast Forwarding?

ETS5 Error 0x80004005 in VLAN-Umgebung beheben?

Preisvergleich

Das könnte dich auch interessieren

Das könnte dich auch interessieren

Hinterlasse einen Kommentar

Schreibe einen Kommentar Antwort abbrechen