Beiträge von Elemir

Zitat von belegdol

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.

Zitat von belegdol

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.

Zitat von belegdol

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.

Zitat von belegdol

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.

Zitat von belegdol

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.

Zitat von belegdol

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.

Zitat von frank_m

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.

Zitat von frank_m

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.

Zitat von pufferueberlauf

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.

Zitat von frank_m

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.

Zitat von Nische

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.

Zitat von frank_m

Wir reden völlig aneinander vorbei.

Das denke ich auch.

Zitat von frank_m

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.

Zitat von frank_m

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.

Zitat von frank_m

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.

Zitat von frank_m

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

Zitat von frank_m

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?

Zitat von frank_m

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.

Zitat von frank_m

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.

Zitat von frank_m

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."

Zitat von airjordan

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.

Ja passt so, wobei mir das egal ist, ich habs nicht wieder aufgewärmt

Danke.

Zitat von Lazze

Moinsen, natürlich bin ich als Admin hier noch aktiv. Elemir wurde damals als SPAM deklariert und meines Wissens entfernt. Es kann aber auch sein, dass das der Versender der Meldung hier entfernt wurden ist Elemir - falls ja, tut mir das leid.

Möchtest du eine Namensänderung in den alten Usernamen?

Hallo, Danke für die Rückmeldung. Ja, eine Rückänderung in Elemir wäre schön, ich selber darf es nicht ("sie dürfen nur alle xxx Tage ...").

Richtig ist, dass ich als Antwort vom Betreiber erhalten hatte, dass mein Account wegen Spamversand gesperrt worden wäre, was aber nicht stimmt, ich kann, ja weiter hier schreiben, nur unter anderem Account-Namen - Logindaten blieben gleich

Entfernt wurde zumindest bzgl. meinem Account nichts.

Richtig ist aber auch, dass ich keinen Spam verschickt hatte (auch nicht jemand anderes von meinem Account aus), sondern dass ich damals dem Spam per "Inhalt melden"-Button gemeldet hatte und "zum Dank" mein User umbenannt wurde. Da hatte wohl jemand Melder und Meldung verwechselt, aber auf einen Hinweis darauf hatte ich keine Antwort vom Betreiber mehr erhalten.

Aber mal ganz ehrlich: das ist doch nicht der Grund für diese absurde Wechselgebühr, das war doch eher zynisch so hingesagt.

Ich kann nur vermuten, dass es sich dabei um einen Fehler handelt, denn worin soll diese hohe Summe begründet sein, wenn der Wechsel in einen höheren Tarif erfolgt. Echte Kosten entstehen kaum, die höhere Auslastung sollte ja über den höheren Tarif abgegolten sein.

Spekulation: man wollte damit Wechsler von DSL zu GF an den Baukosten beteiligen, und hat dabei übersehen, dass es auch Tarifwechsel innerhalb GF trifft. Oder etwas anderes in der Art. Denn gewollt kann das nicht sein, wo doch jeder Provider über vorzeitige Vertragsverlängerungen froh ist, wenn diese nicht in einen niedrigeren Tarif wechseln.

Zitat von HubeBube

Das Mietgerät muss am Ende der Laufzeit dem Provider übergeben werden. Darüber hinaus verhindern diese Geräte üblicherweise die Einstellung von Parametern durch den Kunden.

Man fährt problemloser, wenn nach der Vertragsumstellung auf kundeneigenen Router auch ein selbst erworbenes Gerät genutzt wird.

Unzweifelhaft. Aber wenn man einen laufenden Vertrag mit Mietgerät hat oder gar einen Vertrag, der immer ein Gerät beinhaltet, dann spricht trotzdem nichts dagegen, den Vertrag auf eigenes Gerät umzustellen und den Router dann später auf ein eigenes Gerät umzustellen (außer im Fall, dass das Gerät im Vertrag ist)

Dann wäre es besser, dass alle Kunden, deren MVLZ abgelaufen ist, sich einen anderen Anbieter suchen.

Man muss ja deren Backbone entlasten

Aber Danke für die Warnung, dann weiß man ja schonmal, zu wem man nicht wechseln sollte.

Zitat von pufferueberlauf

Nicht nach EU Verordnung 2015/2120 in der Auslegung der BEREC:

und

Der Drops ist gelutscht, EU Verordnungen sind keine unverbindlichen Empfehlungen...

Schwierig, letztendlich heißt das nur, dass der Provider nichts blockieren darf. Er ist aber nicht verpflichtet, mit jedem einen Vertrag einzugehen, d.h. gewerblichen Nutzen kann er den Vertrag kündigen, muss aber bis zum regulären Kündigungstermin alle Dienste diskriminierungsfrei zur Verfügung stellen.

Zitat von frank_m

Darum ging es in den Fällen aber nicht. Das war ein selbständiger Handwerksbetrieb, der über einen Privatkunden-Anschluss versorgt wurde. Natürlich erwartete der Kunde Service Leistungen wie für einen Business-Anschluss und hat sich entsprechend beschwert. Nur so fiel es überhaupt auf. Anschließend war die DG dann Schuld, weil sie verlangten, dass er einen GK Tarif macht.

In dem Fall ist das wohl unstrittig.

Allerdings kann ich mich an einen Physiotherapeuten erinnern, der einen Kunden zuhause empfing, und DG dann meinte, das seien somit Geschäftsräume. Das ist schon zweifelhaft, weil das noch nichts darüber aussagt, ob dabei der Anschluss überhaupt geschäftlich genutzt wird.

Und ich kann mich hier an Diskussionen erinnern, wo jemand meinte, selbst für Homeoffice bräuchte man einen GK-Vertrag. Nein, und wäre das bei mir der Fall (ich mache Homeoffice am Privatvertrag), würde das ein Gericht entscheiden. Ich bin mir aber sicher, dass es nie dazu kommen wird, denn das ist nur eine Einzelmeinung, die Provider werden ein Urteil in einer solchen Sache vermeiden wollen.