Habe es am Wochenende testen können, von Citrix-Linux-Client zu einem Citrix-Server mit Windows über DGN.
Verbindung läuft stabil, die ausgehende IP-Adresse für EDT- und UDP-Pakete bleibt gleich, konnte auch keinerlei Verbindungsabbrüche feststellen. Daran liegt es also nicht.
Dann bleibt also etwas, was beim Citrix des Ubuntu-Servers anders konfiguriert ist als beim Citrix des Windows-Servers.
Vielleicht mal clientseitig (auf dem Client oder auf dem Router) einen TCP-Dump mitlaufen lassen
Der Vermieter kann keinen Glasfaservertrag für den Mieter abschließen, genauso wenig wie einen VDSL Vertrag.
Habe ich etwas anderes geschrieben?
Der Vermieter kann einzig und allein die Gf-Infrastruktur zur Verfügung stellen
... und muss dazu einen Vertrag mit dem GF-Anbieter abschließen. Insbesondere dann, wenn der GF-Anbieter nicht alle Wohnungen ausbaut, sondern den Anschluss von Wohnungen ohne TK-Vertrag des Mieters dem Vermieter in Rechnung stellt, geht das nicht ohne Vertrag zwischen Vermieter und Anbieter. Wie Du den Vertrag nennen willst bleibt Dir überlassen, aber es ist ein Vertrag.
Implizit fragte ich das an, ich gehe jedoch davon aus, dass der Provider von ohmygodhelp alle Wohneinheiten ausbaut, gleich ob ein Endkundenvertrag vorliegt oder nicht.
Kann man nicht automatisch davon ausgehen. Die Nachbarin hat für jede Wohnung, zu der keine Tarif-Bestellung des Mieters vorlag, bezahlen müssen.
Die Bereitstellung des Kabelanschlusses ist nicht zwingend einem Endkunden-TK-Vertrag gleichzusetzen, daher kann er das als Sammelvertrag für das Haus.
Er darf es als Vermieter nicht (mehr) auf die Mieter umlegen. Genau deswegen kostet es ihn ja und will daher den Vertrag durch Umstellung auf Glasfaser loswerden.
Für mich alles plausibel und korrekt.
Wenn der Netzbetreiber seinen passiven Abschlusspunkt als Ethernetdose definiert faellt auch ein ONT unter diesen Paragraphen. Wie gesagt da gibt es im Bereich FTTB auch Praezedenzfaelle fuer TKG 145 (IIRC gab es da mindestens einen Bericht ueber einen Nutzer der bei NetCologne pauschal fuer die Stromkosten einer VDSL oder G.fast DPU im Keller entschaedigt wurde). Ich bin mir bewusst, dass die Interpretation von Gesetzestexten nicht immer einfach nachvollziehbar ist, aber hier ist der Text relativ klar.
So klar ist das nicht, denn kann ein Ethernetanschluss überhaupt ein passiver Abschlusspunkt für ein Glasfasernetz sein? Wenn der Provider dem Endkunden einen Ethernetanschluss verkauft, dann hast Du mit Deiner Recht, wenn der Provider aber einen Glasfaseranschluss verkauft wird das mit der Interpretation schwierig.
Im Gesetz steht außerdem "soweit erforderlich". Die Praxis bei anderen Providern zeigt, dass es nicht erforderlich ist. Da sollte der Provider also eine gute Begründung haben.
FTTB ist anders gelagert, denn da ist es erforderlich.
Elemir erschreckend. Gibt es keinen besser abgebundenen Mirror?
Doch gibt es. Nutze ich normalerweise auch über Eintrag in apt-cacher-ng. Hat aber zwei Haken: erstens denkt man bei Neuinstallationen nicht sofort dran, den Proxy einzutragen, und wenn der Mirror mal ausfällt oder die Arbeit einstellt, befürchte ich, das nicht unbedingt mitzubekommen.
Beim Original passiert das eher nicht, und Pooladressen wie bei Debian oder Ubuntu gibt es da leider nicht.
Werde heite abend zur Spitzenzeit mal Daten von O2 zum Vergleich posten...
Brauchst Du für mich nicht, ich habe den Vergleich über DGN.
Und Dank VPN zu dem DGN auch einen Workaround, Upstream-Proxy-Eintrag im Squid für packages.linuxmint.com regelt das 
Aber schön ist das halt nicht, war mir schon am Überlegen eine Störung aufzumachen, aber das wird eh verlaufen.
gutes Peering (d.h. keine bekannten sauerhaften Peeringengpaesse zu bestimmten Zielen)*
*) War auch mal bei der Telekom, da konnte ich das vorsaetzliche Unterpeering zu den grossen Transitanbietern zwar messen, aber in meiner normalen Nutzung fiel mir das nicht auf, d.h. ja das Unterpeering ist real aber betrifft die Kunden unterschiedlich stark.
Ich leider schon, packages.linuxmint.com ist bei mir dauerhaft betroffen.
Jetzt gerade:
$> wget --no-proxy http://packages.linuxmint.com/pool/upstream/…ginia_amd64.deb
--2024-11-15 09:01:49-- http://packages.linuxmint.com/pool/upstream/…ginia_amd64.deb
Auflösen des Hostnamens packages.linuxmint.com (packages.linuxmint.com) … 208.77.20.19, 208.77.20.11
Verbindungsaufbau zu packages.linuxmint.com (packages.linuxmint.com)|208.77.20.19|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 107235844 (102M) [application/vnd.debian.binary-package]
Wird in ‘chromium_130.0.6723.116~linuxmint1+virginia_amd64.deb’ gespeichert.
rginia_amd64.deb 4%[ ] 5,10M 33,3KB/s ETA 41m 43s
33,3 KB/s geht einfach nicht, Abends teilweise noch schlimmer.
My traceroute [v0.95]
x (x.x.x.x) -> packages.linuxmint.com (208.77.20.19) 2024-11-15T09:06:41+0100
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. x 0.0% 68 0.9 1.0 0.7 1.4 0.2
2. x 0.0% 68 1.9 2.0 1.6 2.5 0.2
3. x.dip0.t-ipconnect.de 0.0% 68 26.3 4.7 2.6 49.0 6.2
4. m-ef2-i.M.DE.NET.DTAG.DE 0.0% 68 6.7 7.3 6.7 8.2 0.3
5. 80.150.168.185 0.0% 67 14.2 18.7 14.0 144.9 20.1
6. ae21.cr9-chi1.ip4.gtt.net 0.0% 67 109.4 111.2 108.4 136.5 6.3
7. gtt.chi.sharktech.net 13.4% 67 116.8 116.8 116.3 117.3 0.2
8. (waiting for reply)
9. tz06.rt-13.chi.il.tzulo.com 6.0% 67 115.9 116.2 115.5 117.1 0.3
10. static-208-77-20-19.cust.tzulo.com 7.5% 67 119.3 119.4 119.0 120.7 0.3
Derzeit bleibe ich trotzdem bei der Telekom, da die einzige Alternative (wg öffentliche IPv4) derzeit O2 wäre, ich mit denen aber schon andere schlechte Erfahrungen gemacht habe und ich für das o.g. Problem einen Workaround habe (Proxy für die Adresse)
Laut Leistungsbeschreibung wird bei DGN IPv4 über DS-Lite und nicht über CGNAT realisiert.
Ja stimmt, Ich wusste nur nicht, wie ich konkret das NATting auf Providerseite sonst hätte bezeichnen sollen. DS-Lite ist ja mehr als nur NAT, und das Problem ist ja bei DS-Lite und CGNAT gleich.
Das wäre zumindest in der Theorie das gleiche wie bei Vodafone Kabel.
Ja, genau daher ist das von mir auch ziemliche Spekulation, weil das damit nicht zusammenpasst.
Allerdings könnten Einstellungen, wie lange die Information über UDP-Pakete im NAT-Router verbleiben, unterschiedlich sein.
Ist aber hochspekulativ.
Das mit dem öffentlichen IPv4 habe ich mir auch überlegt. Für ein Monat habe ich noch das alte Router. Wenn es bis dahin immer noch nicht klappt, ist es ein Versuch wert. Wenn nicht kann man es hoffentlich dann direkt wieder kündigen.
Das weiß ich leider nicht, da Du ja wie Schwiegervater einen Altvertrag hat. Heute ist es 2,90, bei Altverträgen auf Anfrage kostenlos. Bei Tarifwechseln gelten da die Bedingungen der Altverträge, für die V4 wollen sie trotzdem die 2,90 eines neuen Vertrags.
Je nach wie sehr alles gesperrt ist, kann ich vielleicht schauen, ob sich der Linux Server über EDT oder TCP verbindet. EDT MTU Discovery könnte evtl. das Problem sein, frank_m hat MTU Größe im Verdacht
Ja auch möglich, bin ich nicht drauf eingegangen, weil warum nochmal wiederholten, und mehr kann ich auch nicht beitragen. Ich wollte nur noch eine zweite alternative Idee/Möglichkeit einbringen, die bei uns schon bei Vodafone zugeschlagen hat. Aber gleiches Problem wie bei Dir: ich kann da bei uns nicht reinschauen, macht eine andere Abteilung, und außerdem fehlt mir das Wissen zu Citrix.
Linux-Desktop geht bei uns nicht über Citrix, sondern über x2go. Bei uns leider nicht direkt von Extern per VPN zu verbinden, sondern nur per x2go-Client von einem Citrix-Windows-Desktop aus. Ist aber keine prinzipielle technische Einschränkung von x2go, sondern von der Firma so gewollt.
Ups, habe nicht gesehen, das der Citrix-Server Ubuntu ist - ich war geistig bei einen Ubuntu-Client zu einem Citrix-Server mit Windows. Sorry, dann bin ich wohl nicht hilfreich.
So herum wie Du das hast, haben wir es nicht. Aber meine Erfahrungen mit Citrix und Ubuntu auf dem Client sind eher weniger gut, da wird das auf dem Server nicht so anders sein. Man merkt, dass das Windows-Software ist, die nur für Linux hingefrickelt wurde.
Was wir als VPN nutzen wüsste ich gar nicht, das sehe ich im Citrix nicht direkt, da das alles im Browser und dann im Citrix-Client läuft.
Bei Firmenlaptops mit Windows läuft das auch über Checkpoint.
Citrix an sich (auch mit Windows an beiden Seiten) hat bei uns allerdings Probleme mit IPv4 und CGNAT, wenn die öffentliche IPv4 des CGNAT ständig wechselt, da Default wohl UDP bzw EDT over UDP ist und das CGNAT-Gateway dann möglicherweise die UDP-Verbindungen nicht sauber trackt oder zu kurz offen hält. Die werden auf TCP umgestellt, dann geht es. Das ist mir allerdings bei DGN bei kurzen Tests nicht aufgefallen, das trifft bei uns bisher Kollegen mit TV-Kabel von Vodafone und Windows zu Windows. Aber könnte bei Euch ja ein möglicher Unterschied in der Konfiguration sein und bei DGN zutreffen.
Die genauen Hintergründe kenne ich nicht, ich weiß es nur ungefähr so von Kollegen, die betroffen waren.
Falls Ihr IPv4 nutzt: für 2,90 monatlich gibt es eine öffentliche IPv4 statt CGNAT, eventuell könnte das helfen.
Erklärt dann aber nicht, warum es bei Dir mit Vodafone geht.
Ich kann es versuchen - mal schauen wie experimentfreudig unsere IT Abteilung wird.
Ach so, das Linux ist auch von der Firma und Du kannst das nicht beeinflussen. Das ist schlecht. Bei mir habe ich den Citrix-Client auf eigenem Rechner, da die Firma nur Windows bereitstellt.
Das ist alles bisschen seltsam. Wieso ist nur ein Citrix Remote Desktop betroffen? Macht Citrix Server auf Linux was anders als auf Windows?
Eine ganze Menge, leider ja.
Aus meiner Erfahrung mit Citrix auf Ubuntu: teste mal eine ältere oder neuere Version des Citrix-Clients.
Da ich aber dieselbe Kombination nutze, Citrix auf Ubuntu und mein Schwiegervater DGN hat, kann ich da beim nächsten Besuch mal einen Test machen, wie sich das bei uns verhält. Kann aber ein paar Wochen gehen, falls Du bis dahin keine Lösung hast.
Ist natürlich dann kein Kriterium, weil da zu viele Parameter hineinspielen.
Für sowas gibt es DAD - duplicate Address detection.
Ja, völlig richtig. Daher habe ich die Quelle Wiki genannt, weil ich die Begründung auch nicht wirklich verstehe.
Ganz abgesehen davon: Wenn man zwei Geräte mit gleicher MAC im Netz betreibt, dann hat man noch ganz andere Sorgen, als überschneidende IPv6 Adressen.
Allerdings kann das bei Virtualisierung schneller passieren, als man denkt.
Oder gar absichtlich (oder unabsichtlich) in Loadbalancing-, Failover- oder Hochverfügbarkeitsszenarien; nur wird man da hoffentlich eine feste IP-Vergabe haben und auch ansonsten wissen, was man tut.
Die Idee, dass es eine gute Idee waere eine EInzigartige Hardware ID mit der WEelt zu teilen...
Wiki meint allerdings, der Grund sei, dass bei EUI-64 die Gefahr von Überschneidungen bestünde. Da angeblich einige Hersteller MAC-Adressen schon mehrfach vergeben haben, ist das zwar sehr unwahrscheinlich, aber nicht unmöglich.
Interessant ist da sschon, da man ja theoretisch auch GPON und XGS-PON parallel auf der gleichen Faser betreiben kann. Es gibt Provider, da bekommt man einen XGS ONT nur dann, wenn man den passenden Tarif bucht, andernfalls bekommt man einen GPON ONT.
Allerdings könnte DG dann ein größeres Splitting als 1:64 ohne größere Überbuchung als bisher machen und spart sich den zusätzlichen Aufbau von GPON-Hardware im POP.
Könnte sich dann trotz teureren ONT trotzdem lohnen, wenn man so mit weniger Platzbedarf im POP und in Folge weniger POPs auskommt.
Hab zuerst gedacht VLAN 380 wird zu VLAN 0 oder so, aber auf VLAN 0 scheint nichts zu sein.. also keine Ahnung was hier mit VLAN 380 passiert??
VLAN 0 ist lt. Spezifikation gleichbedeutend mit kein VLAN.
Wir reden völlig aneinander vorbei.
Das denke ich auch.
Der Next Hop hat doch keinen Einfluss auf die Quell- oder Ziel-Adresse des Paketes (es sei denn, wir reden über NAT). Hab ich doch schon oben geschrieben. Natürlich sendet der Node das Paket mit seiner öffentlichen IP ab, und die Ziel-Adresse ist die öffentliche IP des Empfängers.
War nicht irgendwo die Aussage, dass er entweder keine öffentliche hatte oder der Traffic nur mit der link-local sichtbar war?
Wenn dem nicht so dann ok.
Aber dafür ist es doch vollkommen egal, ob der Router auf dem Weg nach draußen (also der Next Hop) eine link-lokale oder eine öffentliche IP hat. Denn dessen Adresse wird nur dafür verwendet, die MAC aufzulösen, denn der Next Hop wird auf Schicht 2 erreicht.
Habe ich das bestritten? Allerdings sollte der Router trotzdem eine öffentliche Adresse besitzen, denn sonst kann er dem Client auch keine per SLAAC zuweisen. Und der Client braucht eine.
Der Unterschied liegt eben nicht in der Quell-IP, denn die ist in beiden Fällen die gleiche. Trenne dich von dem Gedanken, dass Quell-IP und Router-IP im gleichen Subnetz liegen müssen.
Habe ich das behauptet? Ich habe damit gemeint, dass er außer der link-local-Adresse eben noch eine weitere Adresse haben muss, sonst geht das nicht.
Das war nie der Fall (auch nicht bei IPv4!), und wird auch nie der Fall sein. Ja, im klassischen IPv4 NAT-Heimnetz ist es üblicherweise so.
Wird jetzt zwar völig off-topic, aber spätestens wenn Firewalls im Spiel sind, geht es nicht ohne Source-routing. Ja, hat man nicht zuhause.
post-up ip route add 172.x.x.0/24 dev eth0.x src 172.x.x.x table dmz
post-up ip route add default via 172.x.x.1 dev eth0.x table dmz
post-up ip rule add from 172.x.x.x/32 table dmz
post-up ip rule add to 172.x.x.x/32 table dmz
Da haben die Endgeräte aber auch selten mehr als eine IP. Aber es reicht, wenn der Sender des Paketes den Router erreichen kann. Welche Quell-Adresse er ins Paket packt, ist davon völlig unabhängig.
Und deshalb ist der zugrundeliegende Mechanismus des Routings am Ende exakt der gleiche, egal, ob er Next Hop nun eine öffentliche oder eine link-lokale (bzw. private) Adresse hat.
Bei IPv6 ist es tatsächlich üblich, dafür die link-lokalen Adressen zu benutzen. Selbst Fritzboxen die eine öffentliche IPv6 im LAN haben, verteilen als Gateway IP ihre link-lokale Adresse.
Darum geht es doch gar nicht. Den Inhalt des Links nicht gelesen?
Ok, das ist der Unterschied zwischen IPv4 und IPv6, weil man bei IPv4 üblicherweise keine öffentliche Adresse hat am Node (Theoretisch aber genauso denkbar und möglich). Dann stelle dir vor, der Router hätte eine öffentliche IPv6 Adresse anstatt fe80::22. Was wäre der Unterschied? Auch die Adresse wäre nur dafür da, die MAC aufzulösen. Der Next Hop wird immer auf Schicht 2 angesprochen.
Es geht ja nicht um die IP des Router, denn der wird ja wie Du richtig schreibst über die MAC angesprochen.
Es geht um den Empfänger des Paketes (der sich bei einem gerouteten Paket in einem anderen Netzsegment aber mit gleicher link-local-Adresse befindet), welcher (bei TCP) das Antwortpaket schicken soll. Da macht es einen erheblichen Unterschied, ob das empfangene Paket eine link-local (fe80::X) oder eine öffentliche (oder ULA) Adresse enthält. An der Stelle helfen die MACs nicht mehr.
Mit nur einer link-local-Adresse auf dem Client-Interface kann es also nicht funktionieren, wenn geroutet werden soll.
Und wo ist da der Unterschied zu einem "normalen" Gateway? Kein Paket ins Internet wird an die 192.168.178.1 gesendet, sondern an die dazugehörige MAC Adresse. Die Ziel-Adresse bleibt die Adresse im Internet.
Vielleicht hätte ich einen Satz mehr zitieren sollen:
"The host will still send packets sourced from its own global address and destined for the global address of the target."
Der Unterschied liegt also in der Quell-IP. Eine Quell-IP von fe80::X würde keine Antwort auf ein geroutetes Paket erhalten, eine andere (routbare) Quell-IP schon.
Theoretisch ist fe80::22 aber durchaus valide. Mein vServer bei Netcup hat fe80::1 als Default Gateway. Solange man das Gateway erreichen kann und es weiß, wohin mit den Daten, ist das ok.
Achtung, Link-Local-Adressen werden nicht für das Routing verwendet, die Route auf das Link-Local hat andere Gründe. Der Mechanismus ist hier erklärt:
"However, the link-local address in the routing table is used to map to the next-hop’s MAC address in the neighbor cache. The link-local address is not used as a destination address of any of the host’s off-net packets, but rather, is just a way for the host to learn the MAC address of the next-hop router that will forward the host’s IPv6 packets onward to the destination address."
Was ist eigentlich der Vorteil, wenn die 5690 direkt am Glas ist? Der LAN Anschluss zwischen ONT und 5690 kann doch 2,4 gbit oder? Also deutlich mehr als die 1000 Mbit im Glasfaserwan. Und viel Strom wird die ONT auch nicht brauchen, oder?
Für den Normalanwender: weniger Geräte, somit weniger Platzbedarf, nur eine Steckdose und weniger Geräte, um die man sich kümmern muss.
Für den Nerd: Möglichkeit, zusätzlich Glasfaserinformationen zu bekommen (z.B. falls der Provider mal wieder Probleme verneint), Kontrolle über das Gerät und im Defektfall schnellere Austauschbarkeit.
