PPPoE über Switch und LWL

Dann erstelle aber ein seperates Vlan für die PPPoE-Verbindung. Sonst kommt ein heilloses Durcheinander auf dich zu....

- gelöscht -

Und was soll der schwachsinnige Kommentar? Du weisst doch gar nicht, was ich geschrieben hatte und warum ich es wieder gelöscht habe...

Sorry dafür, dass ich Dir helfen wollte. Kommt nicht wieder vor!

Dann schalte sie lieber direkt zu sammen. Ansonsten kann ein Nutzer "zufällig" eine PPoE-Verbindung initieren und das Modem nutzen. Ohne Nutzername und PW funktioniert es zwar nicht, aber wie sich das Modem verhält -???? Außerdem hast du den ganzen Broadcast-verkehr mit auf dem Modem.

- wenn du jedoch nur eine LWL-Leitung hast, kauf eine billigen 8-Port-Vlan fähigen Switch
http://www.amazon.de/dp/B002U08F2S/ref=asc_df_B002U08F2S1367775?smid=A3 ...
oder eine D-Link, oder ähnliches

Das ist ein Avatar und hat nicht das Geringste mit Deiner Frage zu tun.

Wie soll denn ein Layer 3 Protokoll (IP) ein völlig anderes Layer 3 Protokoll (PPPoE) beinflussen?
Richtig: Gar nicht.

Wenn Clients auf der Strecke hängen sind VLANs die einzig saubere Lösung.

Natürlich kann man das technisch auch ohne machen und alles in ein L2-Segment packen.
Man kann aber auch jeden Morgen auf dem Tisch tanzen.

Wenn es natürlich nicht um PPPoE geht sondern um direkten IP-Access geht...dann ändert sich an der Qualität der Lösung nichts.

OT: PPPoE ist kein L3-Protokoll...

Gruß
Steffen

naja - das kommt drauf an wie man sowas aufbaut und wie das ganze netz aussieht. So von nur EINER sauberen lösung zu reden halte ich für mutig...

und wenn die switches kein vlan können dann muss man sich halt was überlegen. Ich z.B. würde das Modem dann direkt durchschalten bis in den serverraum so das es an einem port da aufläuft. Einen Switch dazwischen hängen find ich persönlich nich soo doll - dann hat man nur wieder ne teilstrecke mit vlan und eine ohne -> ein erster ansatz für viel Spass... (denn in 5 jahren weiss keiner mehr was darauf konfiguriert wurde und warum - und ob die Doku jedes 20-Euro-Teil enthält und dann sauber gepflegt wird ist eher fraglich...)

Mir ist kein Kabelnetzbetreiber bekannt, der mit PPPoE arbeitet. Was freilich nichts heißen muss, aber es wäre zumindest ungewöhnlich, wenn es hier so wäre.


Schlimmer ist, dass sämtlicher Ethernettraffic, der an diesem Switchport ausgegeben wird (Broadcasts, Flooding), je nach Konfiguration des Kabelmodems möglicherweise das LAN in Richtung Kabelanschluß verlässt. Sowohl der Provider als auch alle Kunden, die an diesem Strang hängen, können diesen Traffic dann "sehen"! Siehe z.B. http://t-off.khd-research.net/Docs/Internet-Zugang_via_TV-Kab.pdf (Punkt 2).

Gruß
Steffen

Was soll es denn sonst sein?

PPPoE ist ein definiertes Protokoll auf der 3. Netzwerkebene (1: Physikalisch, 2: ARP/MAC, 3: ...), genauso wie IP.
Vielleicht sollten wir es mal IPoE nennen, dann wird die Gemeinsamkeit deutlich

Das kannst du auch hier gerne Nachschlagen:

http://www.iana.org/assignments/ethernet-numbers

Die Definition von Layern auf einer technischen Ebene unterscheidet sich eben von der auf einem OSI-Theorie-Modell.

Wenn du über DSL surfst dann könnte man IP sogar IPoPPPoEoATMoDSLoCopper nennen. An der richtigen Stelle rutscht IP durch das Tunneling also sogar auf Layer 5 hoch.

Jetzt kommt es drauf an welches Modell du ranziehst. Denn z.B. lt. OSI wäre es u.a. Layer 2 ( http://de.wikipedia.org/wiki/Point-to-Point_Protocol ) unterhalb von IP zu finden. Da macht es auch Sinn - weil du darüber ja prinzipiell nicht nur IP verschickst sondern auch ICMP und (würde es die Gegenstelle unterstützen) auch IPX usw. darüber laufen würden.

Daneben könnte man aber auch andere Schichten begründen - da es ja eigentlich nur eine Krankheit ist. Heute hast du ja meistens eh schon "Standleitungen" - d.h. man könnte auch direkt via IP arbeiten. Das PPPoE wird ja eigentlich nur genutzt um z.B. Gebührenimpulse zu übertragen (aus Zeiten als man noch keine Flat hatte bzw. abgeleitet vom PPP-Protokoll). Auch Einwahldaten sind bei einer DSL-Standleitung ja nahezu unnötig - da du eh nur über DEINEN Provider gehen kannst und somit die Verbindung praktisch bis zum Ende drin steht. Von daher kenne ich auch Ansichten bei denen man auch in die höheren Schichten geht - weil eben Einwahldaten usw. beteiligt sind, weil man eine Art DHCP-Protokoll fährt (IP- und DNS-Einstellungen zuweisen),...

Daher ist da das OSI-Modell m.E. kein wirklich gutes Modell um das Protokoll festzulegen... Hier muss man dann eben schon die einzelnen Teilfunktionen betrachten und einzeln einstellen...

Betrachten wir das doch mal aus sich eines ISPs, da ich mich mit dem WISP-Umfeld auch etwas beschäftige:

Am schönsten wäre es wenn ich Ethernet-Traffic direkt zum Kunden bekomme ohne irgendwelche Tunnel - das geht nicht.
1. Problem: In dem Moment wo ich meine Router auf das Netzwerk-Edge setze habe ich ein riesiges Kosten-Nutzen-Problem. Denn ich brauche jetzt vollwertige Router, die a) teuer sind und b) vollständig konfiguriert werden müssen. Da ja jetzt alle meine Router zwischen Peering und Customer-Edge im Internet sichtbar sind müsste ich also auf jedem Router mit komplexen Firewalls und Paket-Routing arbeiten, was die Last auf den Systemen im Vergleich zum reinen Forwarding in die Höhe treibt.
2. Problem: Wenn ich wirklich jeden Router sichtbar mache (und jeder andere ISP würde das auch machen), würden gut über 50% der IP-Pakete an TTLs sterben, weil sich die Hop-Zahl so enorm erhöhen würde. Hinter einem derzeit sichtbaren Hop können sich in Wirklichkeit 10-15 oder mehr verbergen, die einfach durch einen Tunnel verkürzt werden.

Also halten wir fest: IP durch bis zum Kunden geht nicht.

Zweite Möglichkeit: Ich nehme MPLS,GRE,EoIP, etc. und baue einen Tunnel zwischen meinem DSLAM (Access Point) und meinem AC auf und verbinde die Clients so getunnelt mit dem AC, von wo sie eine IP bekommen.
Jetzt habe ich kein Lastproblem mehr und mein Backbone ist sicher, da transparent.
Dafür habe ich jetzt das Problem, dass ich Kunden nicht mehr sicher identifizieren kann, da in diesem einem Tunnel ja 1000 Kunden stecken können und wenn ich mich an die Regeln für gutes Netzdesign halte kann jeder dieser Kunden sein eigenes Modem mitbringen.
Ich kann zwar unterbinden, dass die Kunden direkt miteinander reden können, aber ich kann nicht mehr sicherstellen, dass das was am AC ankommt wirklich zu dem Kunden gehört, der mich interessiert.

Ich muss also jeden Kunden irgendwie in einen eigenen Tunnel bekommen um ihn eindeutig zu identifizieren.
Bei DSL-Netzen ist das kein Problem, da pro Leitung ein Kunde hängt.
Bei WLAN und bei Kabel habe ich aber ein Shared Medium und da ich meine Netzwerksicherheit nicht beim Kunden im Haus machen darf somit das Problem, dass ich gar nicht mit festen Tunneln pro Kunde arbeiten kann.
Dazu würde so ein Tunnel der fest pro Kunde besteht natürlich auch wieder mehr Leistung von meinem Backbone fordern.
Angenommen selbst das klappt, dann habe ich damit ein ganz rechnerisches Problem:

Was darf für mich der Aufwand sein wenn ein Kunde umzieht? - Nichts.
In Kabelgebundenen Netzen habe ich immer den Techniker, der den Port belegen muss. Das ist hier der Minimalaufwand. Bei WLAN-Netzen kann ich das sogar völlig dem Kunden überlassen seine Antenne neu auszurichten.
Meine Netzinfrastruktur muss es also hergeben, dass ein Kunde einfach so mal seinen Anschluss verlegen kann, ohne dass ich dadurch Aufwand habe.
Das klappt mit festen Tunneln nicht.

Schließlich bin ich als Anbieter evtl. gezwungen ein Open Access-Netz zu betreiben, also auch an Reseller weiter zu verkaufen. Hier gilt wieder das selbe: Wie schiebe ich einen Kunden zu einem Reseller, ohne dass mir dadurch Aufwand entsteht?

Wenn man all das betrachtet bleibt für den Kundenzugriff nachher noch eine Technik übrig: PPPoE.

Nur mit PPPoE kann ich ressourcenschonenend viele Kunden eindeutig identifizieren und einen Kunden mit null Aufwand an einen Reseller schieben.

Dann musst Du ARP aber auch als OSI-Layer 3 einstufen, denn das ist Ethertype 2054! Das Typfeld im Ethernetheader sagt (fast) nichts darüber aus, in welche Schicht des OSI-Modells ein Protokoll einzuordnen ist.



Ich glaube zu verstehen, worauf Du hinaus willst und ganz unrecht hast Du damit auch nicht, jedoch richtet sich die grundsätzliche Layer-Einordnung vorrangig nach funktionalen Gesichtspunkten und nicht stur nach der Anzahl der "Zwiebelhäutchen" der tatsächlichen Implementierung. Letzteres allein schon deshalb nicht, weil nahezu beliebiges "Umverpacken" möglich ist und die Anzahl der Layer damit theoretisch unbegrenzt wäre. Ich kann auch Ethernetframes in den Payload höherer Protokollschichten encapsulieren. Natürlich sind die Ethernetframes dann aus Sicht der Netzwerkgeräte, an denen sie im Payload der höheren Protokolle vorbeiziehen, kein Layer 2 mehr. Aber in diesem umverpackten Zustand erfüllen sie auch nicht ihre originäre Funktion, sondern erst dann wieder, wenn sie wieder decapsuliert wurden.
Ethernet ist unstreitig Layer 2, PPP ist Layer 2 und im Ethernetpayload gekapseltes PPP (PPPoE) ist nach herrschender Meinung trotzdem noch nach OSI ein Layer2-Protokoll.



Gruß
Steffen