Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03446.jsonl.gz/103

Fortsetzung von Beitrag Nr. 10 (zu viele Zeichen im Beitrag):
18.) Beim Einsatz von VPN-Tunneln und UDP-Verbindungen sind entsprechende Massnahmen gegen fragmentierte IP-Pakete zu treffen:
https://community.sunrise.ch/t5/Connect-Box/Giga-Connect-Box/m-p/151351#M3221
https://community.sunrise.ch/t5/Connect-Box/Giga-Connect-Box/m-p/153647#M3686
Beim Einsatz von VPN-Tunneln und UDP-Verbindungen sind Massnahmen gegen ICMP-blockierende Firewalls und “Black Hole Router” zu treffen:
https://community.sunrise.ch/t5/Connect-Box/Citrix-und-UPC-Verbindung-sehr-schlecht/m-p/171519#M7731
Beim Einsatz von VPN-Tunneln und UDP-Verbindungen sind Massnahmen gegen die Datenübertragungsrate drosselnde oder blockierende Firewalls zu treffen. Siehe dazu Beitrag Nr. 9 und 12 unter:
https://community.sunrise.ch/t5/Connect-Box/Citrix-und-UPC-Verbindung-sehr-schlecht/m-p/171525#M7734
https://community.sunrise.ch/t5/Connect-Box/Citrix-und-UPC-Verbindung-sehr-schlecht/m-p/171535#M7738
Generell sollten die Hinweise unter:
https://community.sunrise.ch/d/14885-tiefe-bandbreite-bei-ssl-vpn-trotz-higspeed-anschluss/2
zum Einsatz von VPN-Lösungen beachtet werden.
19.) Vorsicht beim Verlegen von Ethernet-Netzwerkkabel in der Nähe von Stromkabel oder in der Nähe von Telefonkabel:
Die hochfrequenten Datenübertragungstechnologien G.fast (Telefonkabel) und Powerline/PowerLAN/PLC (Stromkabel) können die Datenübertragung im Ethernet-Netzwerkkabel stören!
https://de.wikipedia.org/wiki/G.fast
https://de.wikipedia.org/wiki/PowerLAN
Ethernet-Netzwerkkabel nach Cat. 5 oder Cat. 5e ist ausgelegt für hochfrequente Signale bis 100 MHz.
https://de.wikipedia.org/wiki/Twisted-Pair-Kabel#Verbreitete_Twisted-Pair-Kabeltypen_(%C3%9Cbersicht)
Moderne Datenübertragungstechnologien für “Internet über Telefonkabel” wie G.fast nutzen hochfrequente Signale > 100 MHz und können deshalb die Datenübertragung im Ethernet-Netzwerkkabel stören.
https://community.swisscom.ch/t5/Router-Hardware/Endger%C3%A4te-f%C3%BCr-G-fast/m-p/541404#M21891
Moderne Datenübertragungstechnologien für “Internet über Stromkabel” (Powerline/PowerLAN/PLC) nutzen in der Regel hochfrequente Signale < 100 MHz und sollten deshalb die Datenübertragung im Ethernet-Netzwerkkabel nicht stören.
Jedoch sind auf dem Markt bereits Powerline/PowerLAN/PLC-Geräte erhältlich, welche mit hochfrequenten Signalen > 100 MHz arbeiten!
Powerline/PowerLAN/PLC-Geräte, welche mit hochfrequenten Signalen > 100 MHz arbeiten, können die Datenübertragung im Ethernet-Netzwerkkabel stören:
https://www.mittelstandswiki.de/wissen/Hausnetzwerke
20.) Grundsätzlich sollte jedes elektrische Gerät mit Geräte-intern verbauten EMV-Massnahmen genügend gut vor hochfrequenten Störungen aus dem Stromkabel geschützt sein. Stellt sich der Geräte-internen EMV-Schutz als ungenügend heraus, sollte ein Netzfilter im Stromkabel installiert werden. Diese Netzfilter werden auch Entstörfilter genannt.
Solche Netzfilter für Stromkabel findet man in hochwertigen Überspannungsschutzeinrichtungen zum Schutz von teuren Elektronikgeräten vor Blitzeinschlägen, wie zum Beispiel:
- Steckdosenleisten der “Premium Protect”-Linie vom Hersteller Brennenstuhl
- “Shield Protect” vom Hersteller Steffen.
Hochwertige Überspannungsschutzeinrichtungen mit integriertem Netzfilter sind im Fachhandel oder im Online-Versand (zum Beispiel: Digitec) erhältlich.
Beim Einsatz von hochfrequenten Datenübertragungstechnologien wie G.fast oder Powerline/PowerLAN/PLC könnte der Einsatz eines Netzfilter als Schutz vor den hochfrequenten Störsignalen von G.fast und Powerline erforderlich sein. Siehe auch “Gute Performance Regel” Nr. 19.
Das hochfrequente Störsignal von G.fast kann über die Stromversorgung oder “über Luft” auf das Stromkabel überspringen.
https://community.swisscom.ch/t5/Router-Hardware/Endger%C3%A4te-f%C3%BCr-G-fast/m-p/541300#M21839
https://community.swisscom.ch/t5/Router-Hardware/Endger%C3%A4te-f%C3%BCr-G-fast/m-p/541352#M21865
Achtung: Ein Netzfilter hilft nicht gegen Brummschleifen! Für mehr Informationen zum Thema “Brummschleife” siehe Beitrag Nr. 16.
21.) Die eigene Hardware-Firewall/Router muss geeignete Massnahmen gegen Bufferbloat aufweisen.
https://en.wikipedia.org/wiki/Bufferbloat
https://www.bufferbloat.net/
https://community.sunrise.ch/t5/Connect-Box/Internet/m-p/163718#M6092
Als wirksamste Massnahme gegen Bufferbloat gelten Sendewarteschlangen mit Active Queue Management (AQM) oder Smart Queue Management (SQM) wie fq_codel. Für mehr Informationen zu Active Queue Management (AQM) siehe “Gute Performance Regel”-Nr. 29.
https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/
https://en.wikipedia.org/wiki/CoDel
https://www.bufferbloat.net/projects/codel/wiki/
Den Unterschied zwischen AQM und SQM beschreibt diese Webseite:
https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/
Generell empfiehlt sich der Einsatz einer eigenen Hardware-Firewall/Router auf Basis des Linux-Kernels. Linux basierte, moderne Hardware-Firewall/Router unterstützen fq_codel. Aber Achtung: Nicht alle Netzwerkkarten unterstützen unter Linux fq_codel:
https://www.bufferbloat.net/projects/bloat/wiki/BQL_enabled_drivers/
fq_codel kann wie folgt unter Linux aktiviert werden:
# more /etc/sysctl.conf |grep -i qdisc
net.core.default_qdisc = fq_codel
# ip addr show
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
Damit fq_codel wirksam ist, muss die Datenübertragungsrate in beiden Richtungen (Downstream + Upstream) künstlich gedrosselt werden:
https://wiki.untangle.com/index.php/Bufferbloat
https://www.lancom-forum.de/fragen-zum-thema-firewall-f15/qos-funktioniert-nicht-korrekt-bei-wan-ethernetans-t14326.html#p86139
Damit sich die Datenpakete in der Sendewarteschlange der eigenen Hardware-Firewall/Router stauen. Die künstliche Drosselung der Datenübertragungsrate in der eigenen Hardware-Firewall/Router muss so dimensioniert sein, dass:
a) nie ein Datenpaketstau in der Sendewarteschlange des EuroDOCSIS-Kabelmodem entstehen kann (=> Upstream => Upload-Richtung).
UND
b) nie ein Datenpaketstau in der Sendewarteschlange des CMTS entstehen kann (=> Downstream => Download-Richtung).
https://community.sunrise.ch/d/15737-disconnect-ea-fifa21-hohe-pings/39
Zum Beispiel:
Ein EuroDOCSIS-Kabelmodem wurde von UPC Cablecom mit einem 100 MBit/s-Internetabo profiliert. Das ergibt unter der Beachtung der üblichen 10 % Überprofilierung Bruttodatenübertragungsraten von:
110 MBit/s im Downstream (Download-Richtung)
11 MBit/s im Upstream (Upload-Richtung)
In diesem Beispiel muss die eigene Hardware-Firewall/Router für eine künstliche Drosselung auf:
100 MBit/s im Downstream
10 MBit/s im Upstream
konfiguriert werden, damit sich die Datenpakete bei Hochlast in der gewünschten Sendewarteschlange stauen. Erwünscht ist ein Datenpaketstau in der Sendewarteschlange der eigenen Hardware-Firewall/Router. Unerwünscht ist ein Datenpaketstau in der Sendewarteschlange des EuroDOCSIS-Kabelmodems oder im CMTS.
Der Datenpaketstau muss sich in der eigenen Hardware-Firewall/Router sowohl in der Sendewarteschlange des WAN-Ports (Internetanschluss), wie auch in der Sendewarteschlange des LAN-Ports bilden (Anschluss Heimnetzwerk).
Der WAN-Port muss mit einem geeigneten AQM/SQM (zum Beispiel: fq_codel oder cake) konfiguriert sein und über eine künstliche Drosselung der Datenübertragungsrate im Upstream (Upload-Richtung) verfügen.
Jeder verwendete LAN-Port muss mit einem geeigneten AQM/SQM (zum Beispiel: fq_codel oder cake) konfiguriert sein und über eine künstliche Drosselung der Datenübertragungsrate im Downstream (Download-Richtung) verfügen.
Vor der Aktivierung von AQM/SQM muss man abklären, ob die eigene Hardware-Firewall/Router über genügend Performance für den AQM-/SQM-Betrieb aufweist! Siehe dazu:
https://community.sunrise.ch/d/19626-ubiquiti-unifi-security-gateway/10
und unter:
https://www.increasebroadbandspeed.co.uk/review-ubiquiti-unifi-dream-machine-udm-pro
die Tabelle “Table 1”, Zeile “Max. SQM throughput”.
Für die Unterstützung, Aktivierung und Konfiguration von AQM/SQM siehe auch:
Die mehrjährige Weiterentwicklung von fq_codel ist in CAKE eingeflossen. CAKE gilt als der zur Zeit beste AQM/SQM für Linux-Rechnern und auf Linux-basierende, eigene Hardware-Firewalls/Routern.
https://www.bufferbloat.net/projects/codel/wiki/Cake/
https://www.bufferbloat.net/projects/attachments/150817135028_cake-battlemesh-v8.pdf
https://forum.mikrotik.com/viewtopic.php?p=820318#p772784
Für die Konfiguration von CAKE siehe die entsprechende Man-Seite auf einem Linux-Rechner:
$ man tc-cake
https://www.man7.org/linux/man-pages/man8/tc-cake.8.html
Eine ausführliche Anleitung zur Installation und Konfiguration von CAKE auf einem Linux-Rechner findet man im entsprechenden Beitrag unter:
https://www.lancom-forum.de/fragen-zum-thema-firewall-f15/bandbreite-zum-surfen-zur-ausenstelle-begrenzen-t17321.html
Unterstützt die Hardware-Firewall/Router kein Active Queue Management (AQM), sollte auf die künstliche Drosselung in der Hardware-Firewall/Router verzichtet werden. In diesem Fall überlässt man das AQM besser dem EuroDOCSIS 3.1-fähigen-Kabelmodem und dem CMTS. Alle EuroDOCSIS 3.1-fähigen Kabelmodeme unterstützen AQM. Siehe dazu “Gute Performance Regel”-Nr. 29.
Ein EuroDOCSIS 3.1-fähiges Kabelmodem von UPC-Sunrise ist die “Giga Connect Box”.
Die “Connect Box” ist ein EuroDOCSIS 3.0-fähiges Kabelmodem und unterstützt kein AQM!
AQM/SQM auf der eigenen Hardware-Firewall/Router oder AQM auf dem EuroDOCSIS 3.1-fähigen Kabelmodem testen:
https://www.waveform.com/tools/bufferbloat
Hinweise zu Bufferbloat und den Bufferbloat-Tests unter:
https://community.sunrise.ch/d/8427-wird-upc-jemals-konkurrenzfahig-mit-glaseranbieter
beachten!
Bufferbloat-Testresultate eines EuroDOCSIS 3.0-fähigen Kabelmodems (EVM 3236; Bridge-Modus) mit einem Linux-Rechner mit AQM/SQM CAKE im Upstream und einer künstlichen Drosselung auf 10.5 MBit/s im Upstream. Im Downstream wirkt ebenfalls CAKE mit einer künstlichen Drosselung auf 80 MBit/s im Downstream. Internetabo: 100/10 MBit/s.
Die relevanten Konfigurationsschritte des Linux-Rechner zu den oben abgebildeten Messresultate entnimmt man unter:
https://www.lancom-forum.de/fragen-zum-thema-firewall-f15/bandbreite-zum-surfen-zur-ausenstelle-begrenzen-t17321.html#p106507
Weitere Informationen zum Testen und Messen von Bufferbloat:
https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bufferbloat/
22.) Zeitkritische Anwendungen wie VoIP-Sprachtelefonie, Gaming, NTP sollten in der eigenen Hardware-Firewall/Router per QoS-Mechanismus bevorzugt behandelt werden.
Ein guter Einstieg ins Thema “QoS” bietet:
https://www.msxfaq.de/netzwerk/qos/index.htm
Zeitkritische Anwendungen werden üblicherweise über UDP-Verbindungen abgewickelt. TCP-Verbindungen eignen sich nicht (ohne ECN) oder nur bedingt (mit ECN) für zeitkritische Anwendungen. Zum Thema “ECN” siehe “Gute-Performance-Regel”-Nr. 29.
Diese zeitkritischen UDP-Datenpakete sollten in der Sendewarteschlange der Hardware-Firewall/Router bevorzugt behandelt werden (priorisiert). Damit diese zeitkritischen UDP-Datenpakete weniger lang in der Sendewarteschlange warten müssen.
Diese zeitkritischen UDP-Datenpakete werden üblicherweise auf Layer 3 (IP) per DiffServ (DSCP) für die bevorzugte Behandlung markiert (zum Beispiel: “EF”).
https://en.wikipedia.org/wiki/Differentiated_services
Auf Layer 2 erfolgt die entsprechende Markierung für die bevorzugte Behandlung in Ethernet-Netzwerken per VLAN-PCP (IEEE 802.1Q -> Priority code point (PCP) -> IEEE 802.1p).
https://de.wikipedia.org/wiki/Virtual_Local_Area_Network
https://en.wikipedia.org/wiki/IEEE_802.1Q
https://de.wikipedia.org/wiki/IEEE_802.1p
https://thenetworkstack.com/hp-switch-provision-qos-guide/
https://www.felser.ch/papers/2019-WP-TSN-Measurements.pdf
https://www.lancom-forum.de/fragen-zum-thema-firewall-f15/bandbreite-zum-surfen-zur-ausenstelle-begrenzen-t17321.html#p106555
Im WLAN erfolgt die bevorzugte Behandlung von Datenpakete per WMM/WME nach dem Standard IEEE 802.11e:
https://de.wikipedia.org/wiki/IEEE_802.11e
https://www.lancom-forum.de/fragen-zum-thema-firewall-f15/bandbreite-zum-surfen-zur-ausenstelle-begrenzen-t17321.html#p106555
Für zeitkritische Anwendungen sollten in der Hardware-Firewall/Router per QoS-Mechanismus Mindestbandbreiten im Upstream und Downstream reserviert werden. Die Konfiguration von Mindestbandbreiten stellt sicher, dass in Hochlastsituationen genügend Datenübertragungskapazität für die zeitkritischen Anwendungen zur Verfügung steht.
Unterstützt die eigene Hardware-Firewall/Router AQM/SQM mit mehreren Warteschlangen nach fairem Verteilprinzip (Fair-Queuing -> fq) UND mit Massnahmen gegen zu lange Warteschlangen (zum Beispiel: CoDel -> Kombination ergibt: fq_codel) ist:
- die Reservation von Mindestbandbreiten im Up- und Downstream
nicht erforderlich!
https://de.wikipedia.org/wiki/Fair-Queuing
https://en.wikipedia.org/wiki/CoDel
https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/
Damit QoS respektive AQM/SQM in der Hardware-Firewall/Router auch wirksam ist, muss die Datenübertragungsrate des Internetanschlusses künstlich gedrosselt werden. Siehe vorgängige Regel für mehr Informationen zur künstlichen Drosselung.
Für QoS beim Einsatz von Microsoft Teams siehe:
https://www.lancom-forum.de/fragen-zur-lancom-systems-routern-und-gateways-f41/ms-teams-quality-of-service-t18478.html
Für die Unterstützung, Aktivierung und Konfiguration von QoS (und SQM) auf der eigenen Hardware-Firewall/Router siehe auch:
https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/228_Internetzugang-fur-wichtige-Netzwerkgerate-und-anwendungen-priorisieren/
23.) Alle Anfragen für die Namensauflösung (DNS) aus dem Heimnetzwerk sind an den DNS-Forwarder in der eigenen Hardware-Firewall/Router zu richten. Die eigene Hardware-Firewall/Router wird im weiteren nur noch “Home-Router” genannt. Der auf dem Home-Router laufende DNS-Fowarder leitet alle nicht selber beantwortbaren DNS-Anfragen an den DNS-Forwarder des ISP (hier: UPC Cablecom) weiter.
https://de.wikipedia.org/wiki/Domain_Name_System
https://www.msxfaq.de/internet/publicdnsprovider.htm
https://www.msxfaq.de/cloud/verbindung/dnsmalwarefilter_und_cloud.htm
Es gilt das Sprichwort:
A busy name server is a happy name server
Quelle: https://securityblog.switch.ch/tag/powerdns/
Aus Performancegründen und zur Vermeidung von fragmentierten IP-Datenpakete sollten nur die DNS-Forwarder des ISP (UPC Cablecom) vom Home-Router für die Namensauflösung (DNS) verwendet werden. Siehe auch:
https://community.sunrise.ch/t5/Connect-Box/Giga-Connect-Box/m-p/151351#M3221
https://community.sunrise.ch/t5/Sicherheit/DNSSEC-nicht-verf%C3%BCgbar/m-p/115357#M250
Aus Performancegründen muss der auf dem Home-Router laufende DNS-Forwarder alle Antworten vom DNS-Forwarder des ISP zwischenspeichern können (DNS-Cache). Zahlreiche DNS-Anfragen kann der auf dem Home-Router laufende DNS-Forwarder sehr schnell mit der im Zwischenspeicher (DNS-Cache) gespeicherten Antwort auf die vorgängig von einem anderen Heimnetzwerkteilnehmer getätigten DNS-Anfrage beantworten (Antwortzeit < 1 ms).
Der DNS-Forwarder auf dem Home-Router muss das Zwischenspeichern (DNS-Cache) von Antworten auf DNS-Anfragen über UDP Port 53 UND TCP Port 53 (RFC 7766) unterstützen.
Ideal ist der Einsatz von unbound auf dem Home-Router. Unbound kann so konfiguriert werden, dass im Regelbetrieb alle DNS-Anfragen an den DNS-Forwarder vom ISP gesendet werden. Fällt der DNS-Forwarder aus, kann Unbound als DNS-Resolver arbeiten und alle DNS-Anfragen aus dem Heimnetzwerk/Firmennetzwerk selber beantworten.
https://community.sunrise.ch/d/19158-dns-problem/9
Ausschnitt aus /etc/unbound/unbound.conf für den oben beschriebenen Betrieb von Unbound:
forward-zone:
name: “.”
forward-addr: <ip-pii>
forward-addr: <ip-pii>
forward-addr: <ip-pii>
forward-addr: <ip-pii>
forward-first: yes
Der Ausschnitt aus unbound.conf enthält die IP-Adressen von zwei DNS-Forwardern vom ISP UPC-Sunrise (Hauptleitung über Fernsehkabelnetzwerk -> EuroDOCSIS) und IP-Adressen von zwei DNS-Forwardern vom ISP Swisscom (Backupleitung über Mobilfunk).
Vorsicht beim Einsatz von dnsmasq: Dnsmasq unterstützt erst ab Version 2.81 das Zwischenspeichern von DNS-Anfragen über TCP Port 53 (RFC 7766)!
http://www.thekelleys.org.uk/dnsmasq/CHANGELOG
http://www.thekelleys.org.uk/dnsmasq/doc.html
Die Performance des DNS-Cache von DNSMasq kann mit dem Eintrag:
cache-size=10000
in der DNSMasq-Konfigurationsdatei /etc/dnsmasq.conf weiter verbessert werden.
Aus Sicherheitsgründen sollte mindestens der auf dem Home-Router laufende Home-Router DNSSEC unterstützen. Siehe dazu:
https://community.sunrise.ch/t5/Sicherheit/DNSSEC-nicht-verf%C3%BCgbar/m-p/115357#M250
Alle den auf dem Home-Router laufende DNS-Forwarder umgehende DNS-Anfrageverfahren sind auf allen Heimnetzwerkteilnehmer und für alle darauf laufenden Programme auszuschalten. Ein bekanntes solches Verfahren ist “DNS over HTTPS” (DoH => RFC 8484). Unterstützung von “DNS over HTTPS” ist auszuschalten bei:
- Android-Mobilgeräte
- Webbrowser Firefox
Dasselbe gilt für ähnliche DNS-Anfrageverfahren wie DNSCrypt, DNS over QUIC und so weiter.
https://de.wikipedia.org/wiki/DNS_over_HTTPS
https://www.golem.de/news/doh-standard-dns-ueber-https-ist-besser-als-sein-ruf-1907-142624.html
https://www.heise.de/ct/artikel/Mozilla-aktiviert-umstrittene-Verschluesselung-in-Firefox-4679132.html
https://www.heise.de/newsticker/meldung/DNS-over-HTTPS-Ein-Problem-geloest-mehrere-neue-geschaffen-4350674.html
24.) Beim Einsatz des EuroDOCSIS-Kabelmodem “Giga Connect Box” ist darauf zu achten, dass die eingesetzte “Giga Connect Box” Hardware-Revision 8 oder höher aufweist. Siehe:
https://community.sunrise.ch/d/9065-giga-internet-weniger-speed-als-vorher/7
https://community.sunrise.ch/d/15136-unterbruche-aussetzer-ms-teams
https://community.sunrise.ch/t5/Connect-Box/Massive-Probleme-mit-Giga-Connect-Box/m-p/165382#M6433
Darauf achten, dass ein möglichst neues Netzteil eingesetzt wird:
https://community.sunrise.ch/t5/Connect-Box/Massive-Probleme-mit-Giga-Connect-Box/m-p/165450#M6461
25.) Vorsicht beim Einsatz von Netzwerkkarten die per USB mit dem Mobilgerät oder PC verbunden sind. Nicht alle USB-Netzwerkkarten unterstützen Datenübertragungsraten bis 940 MBit/s! Siehe für mehr Informationen:
https://community.sunrise.ch/t5/Connect-Box/langsamere-Daten%C3%BCbertragung-per-LAN/m-p/166704#M6707
Vorsicht beim Einsatz von Netzwerkkarten in mit USB-C-Kabel (USB-C oder Thunderbolt) angebundenen Dockingstations.
https://de.wikipedia.org/wiki/Dockingstation
Und Vorsicht bei modernen Bildschirmen, die per USB-C-Kabel (USB-C oder Thunderbolt) mit dem Laptop verbunden werden und eine (USB-)Netzwerkkarte enthalten. Einige mit USB-C-Kabel angeschlossenen Netzwerkkarten können die Datenübertragung über das Ethernet-Netzwerkkabel empfindlich stören. Siehe dazu:
Wird ein per USB-C angeschlossenes Gerät als Übeltäter für Netzwerkprobleme verdächtigt, sollte die Firmware aller an der USB-/Thunderbolt-Datenübertragung beteiligten Komponenten auf den aktuellsten Stand gebracht werden. Zum Beispiel:
- Mobilgerät mit USB-C-/Thunderbolt-Anschluss (Laptop, Smartphone, Tablet)
- PC mit USB-C-/Thunderbolt-Anschluss
- USB-Netzwerkkarte mit USB-C-Anschluss
- Dockingstation mit USB-C-/Thunderbolt-Anschluss
- Bildschirm mit Ethernet- und USB-C-Anschluss
26.) Der Einsatz von IPv6-Überbrückungslösungen wie Teredo, 6in4, 6to4, 6rd ist aus Performance- und Sicherheitsgründen nicht zu empfehlen. Die Unterstützung aller IPv6-Überbrückungslösungen sollte auf allen Netzwerkteilnehmer im Heimnetzwerk ausgeschaltet werden.
https://community.sunrise.ch/t5/Connect-Box/XBOX-NAT-Typ-mit-IPV6-DS-Lite/m-p/171097#M7642
Dies gilt besonders für die IPv6-Überbrückungslösung Teredo, welche bei Windows-Betriebssystemen (inklusive XBox) standardmässig eingeschaltet ist. Siehe auch:
https://community.sunrise.ch/t5/Connect-Box/XBOX-NAT-Typ-mit-IPV6-DS-Lite/m-p/171097
27.) Aus Performance- und Sicherheitsgründen sollten keine VPN-Tunnel zu Bezahldienste wie NordVPN, Surfshark und so weiter, realisiert werden. Von VPN-Tunneln, wo mindestens ein VPN-Endpunkt von einer Fremdperson betrieben wird, sollte man aus Sicherheitsgründen die Finger lassen. Zum Beispiel:
https://www.heise.de/security/meldung/NordVPN-Co-Hacker-stiegen-in-Server-von-verschiedenen-VPN-Anbietern-ein-4563846.html
28.) Unterstützung von TKIP auf dem Wireless Access Point ausschalten:
https://community.sunrise.ch/t5/Connect-Box/WLAN-sicherheitshinweis/m-p/174559#M8268
29.) Immer mehr moderne Netzwerkkomponenten unterstützen Explicit Congestion Notification (ECN) für TCP-Verbindungen.
https://en.wikipedia.org/wiki/Explicit_Congestion_Notification
https://networkingharder.wordpress.com/2020/08/29/explicit-congestion-notification-ecn-explained/
Immer mehr moderne Netzwerkkomponenten unterstützen Sendewarteschlangen mit Active Queue Management (AQM).
https://en.wikipedia.org/wiki/Active_queue_management
Active Queue Management (AQM) kommt oft als Massnahme gegen Bufferbloat zum Einsatz. Für mehr Informationen zum Thema “Bufferbloat” und “AQM” siehe “Gute Performance-Regel”-Nr. 21.
Am wirksamsten ist AQM in Kombination mit ECN.
https://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf
Deshalb sollte auf allen Rechnern für möglichst alle TCP-Verbindungen ECN eingesetzt werden. Wie man ECN auf einem Rechner aktiviert, beschreibt diese Webseite:
https://www.bufferbloat.net/projects/cerowrt/wiki/Enable_ECN/
Achtung: Vor der Aktivierung von ECN sollten die Angaben unter:
https://community.sunrise.ch/d/15398-ecn-filterung-durch-isp-upc-sunrise
beachtet werden, ob der ISP UPC-Sunrise in Zwischenzeit die Probleme mit ECN behoben hat!
Wie man die ECN-Unterstützung auf Apple-Rechnern (Mac OS X) ausschaltet, beschreiben die ECN-relevanten Beiträge unter:
https://community.sunrise.ch/d/18281-gigabox-schwacher-upload-speed
Mit AQM in Kombination mit ECN informiert die Netzwerkkomponente (Router, Switch, Kabelmodem und so weiter…) frühzeitig den Sender der TCP-Datenpakete (Client oder Server), dass die Sendewarteschlange zu lang wird, die Wartezeite für die zu versendenden TCP-Datenpakete in der Sendewarteschlange zu hoch sind und deshalb der Sender die Datenrate der zu versendenden TCP-Datenpakete rasch möglichst drosseln soll.
Mit AQM in Kombination mit ECN wird vermieden, dass IP-Datenpakete von Netzwerkkomponenten verworfen werden (DROP), weil die Sendewarteschlange zu lang wird, sprich “überläuft”. Der Versand von verworfenen IP-Datenpakete (DROP) muss wiederholt werden, was zu erheblichen Verzögerungen im Datenpaketversands führt (Latenz/Latency steigt).
Auch lange Sendewarteschlangen führen zu erhebliche Verzögerungen im Datenpaketversand (=> messbar höhere Latenz/Latency).
https://www.cablelabs.com/how-docsis-3-1-reduces-latency-with-active-queue-management
EuroDOCSIS 3.1-fähige Kabelmodeme wie die “Giga Connect Box” von UPC-Sunrise unterstützen AQM und “Low Latency DOCSIS”. Beides sind wirksame Massnahmen zur Verringerung der Verzögerungen im Datenpaketversand (=> messbar tiefere Latenz/Latency).
https://www.cablelabs.com/how-docsis-3-1-reduces-latency-with-active-queue-management
https://www.cablelabs.com/technologies/low-latency-docsis
https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=0affb960-25f4-44f9-b747-74ad8555fd06&__hstc=217413636.c7da90edb3c9e298e0b05baeb3317518.1557509545678.1557786603001.1557789533082.8&__hssc=217413636.104.1557789533082&__hsfp=3956899065
https://www.cablelabs.com/technologies/docsis-3-1
Dank “Low Latency DOCSIS” werden Datenpakete von TCP-Verbindungen, deren Client UND Server ECN aktiv unterstützen, vom EuroDOCSIS 3.1-fähigen Kabelmodem und seiner Gegenstelle, dem CMTS, bevorzugt behandelt. Dies führt zu messbar tieferen Werte der Latenz/Latency von TCP-Verbindungen mit ECN zu TCP-Verbindungen ohne ECN.
Damit EuroDOCSIS 3.1-fähige Kabelmodeme mittels “Low Latency DOCSIS” auch UDP-Datenpakete bevorzugt behandeln, müssen diese bevorzugt zu behandelnden UDP-Datenpakete von der eigenen Hardware-Firewall/Router beim Versand über den WAN-Port an das EuroDOCSIS-Kabelmodem per DiffServ (DSCP) mit “EF” markiert werden.
https://en.wikipedia.org/wiki/Differentiated_services
Für mehr Informationen zum Einsatz von DiffServ (DSCP) bei “Low Latency DOCSIS” siehe die EuroDOCSIS 3.1-Spezifikation “MAC and Upper Layer Protocols Interface” (Dokumenten-ID: CM-SP-MULPIv3.1), Kapitel 7.7 “Low Latency DOCSIS”:
https://www.cablelabs.com/specifications/CM-SP-MULPIv3.1
Für Gamer ist die Latenz respektive Paketumlaufzeit (RTT, Latency, lag, ping time) “spielentscheidend”:
https://community.sunrise.ch/d/14959-ps5-ps4-lags-und-paketverluste-unspielbar-mit-giga-connect/4
https://mobilecommunity.ch/wbb/index.php?thread/326-salt-fiber-oder-salt-unlimited-surf-f%C3%BCr-heimnetzwerk/&postID=2526#post2526
Darauf achten, dass der eingesetzte AQM auch entsprechend konfiguriert wurde, dass er ECN unterstützt. Siehe dazu unter Linux-Rechnern die Man-Seite des eingesetzten AQM. Zum Beispiel:
$ man tc-fq_codel
https://www.man7.org/linux/man-pages/man8/tc-fq_codel.8.html
$ man tc-codel
https://man7.org/linux/man-pages/man8/tc-codel.8.html
$ man tc-pie
https://man7.org/linux/man-pages/man8/tc-pie.8.html
$ man tc-fq_pie
https://www.man7.org/linux/man-pages/man8/tc-fq_pie.8.html
Bitte in Beitrag Nr. 10 weiterlesen.