MoCA über SAT-Koax mit Juniper Switches
27.08.2026 3 Min. Lesezeit
MoCA-Bridge hinter Juniper EX2300: Ethernet-Port “up”, aber tot - IEEE 802.3az als Ursache
Kurzfassung: MoCA-2.5-Bridge (Kiwee KB-M3-02E, MaxLinear GPY211-PHY) an einem Juniper EX2300.
Symptom: Der Switch-Port zur Bridge bleibt link-up, zeigt keine Fehler-Counter, aber die MAC-Adresstabelle für den Port ist leer - es kommt schlicht kein Frame mehr an.
Ursache: Der GPY211-PHY implementiert ein herstellerspezifisches “Smart-AZ”-Feature, das IEEE-802.3az-Energiesparzustände (EEE) auch gegenüber einem Link-Partner ohne EEE-Unterstützung einleiten kann. Der EX2300 unterstützt 802.3az, hat es aber nicht per Default aktiv.
Fix: 802.3az auf dem betroffenen Interface explizit aktivieren.
Symptom
Betroffener Port bleibt laut Switch durchgehend “up”, keine Carrier-Transitions, keine CRC-/Framing-Fehler:
show interfaces <if> extensive | match "errors|carrier"
Trotzdem ist die MAC-Adresstabelle für den Port leer:
show ethernet-switching table interface <if>
Kein ARP, kein Broadcast, kein einziges Frame kommt an. Ein Link-Bounce oder ein Power-Cycle der Bridge stellt die Verbindung sofort wieder her - bis zum nächsten Ausfall, typischerweise nach einigen Stunden, manchmal bereits nach wenigen Minuten.
Ursache
Der GPY211 (MaxLinear) implementiert laut Datenblatt “Smart-AZ”: Unterstützung für Energy Efficient Ethernet (EEE, IEEE 802.3az) auch mit MAC-Partnern, die selbst kein EEE aushandeln. Regulär wird EEE ausschließlich während der Autonegotiation zwischen beiden Link-Partnern vereinbart (Next-Page-Exchange nach Clause 78); Smart-AZ umgeht diese Voraussetzung und kann Low-Power-Idle-Zustände (LPI) einseitig gegenüber einem Partner einleiten, der davon nichts weiß.
Der EX2300 unterstützt 802.3az, aktiviert es aber nicht automatisch - es muss pro Interface explizit gesetzt werden. Ohne aktiviertes 802.3az auf Switch-Seite interpretiert der Switch die vom PHY einseitig eingeleiteten LPI-Signale nicht korrekt: Der Link-Layer (Layer 1) bleibt bestehen, der Frame-Forwarding-Pfad hängt.
Charakteristisch für dieses Fehlerbild: Es betrifft bevorzugt Ports mit unregelmäßigem Traffic-Muster (Phasen mit wenig bis keinem Verkehr, unterbrochen von Bursts) - also z. B. einen MoCA-Uplink mit Broadcast-/ARP-/mDNS-Hintergrundrauschen und dazwischenliegenden Idle-Phasen. Ein Port mit konstant hoher Auslastung zeigt das Symptom seltener, weil er kaum in einen LPI-Zustand fällt, aus dem er nicht sauber zurückfindet.
Fix
802.3az auf dem betroffenen Interface aktivieren:
set interfaces <if> ether-options ieee-802-3az-eee
EEE wird nur während der Autonegotiation ausgehandelt - ein zuvor fest auf Speed/Duplex gepinnter Port (z. B. als Workaround für andere PHY-Interop-Probleme) muss dafür wieder auf Autoneg zurückgesetzt werden:
delete interfaces <if> ether-options no-auto-negotiation
Verifikation, dass EEE tatsächlich aktiv ausgehandelt wurde:
show interfaces <if> extensive | match eee
Ergebnis
Nach Aktivierung lief die Verbindung über mehrere Tage durchgehend stabil (inkl. eines vollen Werktags mit Home-Office-Last über die Bridge), keine Ausfälle, PHY-Rate unverändert bis leicht verbessert. Zuvor: Ausfall alle paar Stunden, zwingend manueller Eingriff zur Wiederherstellung.
Für wen relevant
Jede Kombination aus einem MaxLinear-GPY211-basierten Ethernet-Endpunkt (nicht nur MoCA-Bridges - der Chip findet sich auch in Routern und Access Points) und einem Switch, der 802.3az unterstützt, aber nicht per Default aktiviert (neben Juniper EX-Serie vermutlich weitere Enterprise-Switches mit demselben Verhalten). Consumer-Switches ohne jegliche EEE-Unterstützung oder mit immer aktivem EEE zeigen dieses spezifische Interop-Problem typischerweise nicht - daher ist es mit einfacher Heimnetzwerk-Hardware kaum reproduzierbar und leicht zu übersehen.