IP-Routing zum DSL-Interface (zum VDSL-Modem)

[Massa]

Hallo,

mein VDSL-Modem, das Speedport 300HS, ist seit kurzem leicht "gemoddet" (für Details siehe im Thread im Online-Kosten Forum).
Damit kann ich, wenn ich das Modem mit seiner dann vorhandenen IP-Adresse 192.168.1.99 anspreche, per Web-Interface einige VDSL-Parameter auslesen.

Leider geht das momentan nur, wenn ich mich mit dem Kabel direkt mit dem Modem verbinde, da das Speedport 701 mit Freetz natürlich keine IP-Adresse zum DSL-Modem hin hat (WAN-Port).

Ich habe jetzt versucht (erstmal per Kommandozeile), dem Interface ein entsprechende IP-Adresse zu geben und entsprechendes Routing einzurichten, so dass ich das Modem aus dem internen Netzwerk aus ansprechen kann.
Das hat aber bisher nicht funktioniert

Ich komme mit den ganzen Interfaces auf der Box nicht klar.
Welches ist denn das Interface, dass den WAN-Port repräsentiert (ohne PPPOE-Verkapselung)?
Ich habe folgende auf meiner Box:

cpmac0, dsl, eth0, lan, lo, tiwlan0-tiwlan3, wan, wdsdw0-wdsdw3, wdsup0

Einige habe ich jetzt bereits ausprobiert (wan, lan, dsl) und mit der Adresse 192.168.1.1 versorgt:

ifconfig dsl 192.168.1.1 broadcast 192.168.1.255
route add -net 192.168.1.0 netmask 255.255.255.0 dsl

Aber leider funktionierte ein ping auf's DSL-Modem bei keinem von ihnen.
Und meistens ist damit dann auch die Internetverbindung weg und ich kann den 701'er rebooten

Hat jemand eine Idee, was ich machen kann?

 

[meyergru]

Das ist tatsächlich nicht so einfach. Im Originalthread bei Onlinekosten hat es auch noch keiner ohne vorgeschalteten Switch geschafft.

Ich sehe da zwei Hauptprobleme:

1. Es muß eine Back-Route in Dein LAN im 300HS eingetragen werden, anderenfalls kannst Du "vorwärts" eintragen, was Du willst. Bei mir scheitert das Eintragen per Webinterface mit einer Fehlermeldung ("200: Gateway IP unreachable" oder so).

2. Selbst, wenn Du das richtige Interface findest ("echte" Kandidaten sind cpmac0, eth0 und wan) und konfigurierst, hast Du das Problem, daß dieses ausgerechnet bei VDSL-Betrieb im VLAN-Modus (VLAN ID 7) arbeitet. Das macht AVM aber nicht mit Linux-Bordmitteln (vconfig), damit könnte man ja mehrere virtuelle Interfaces mit unterschiedlichen VLAN-IDs öffnen (z.B. "cpmac0.7" und "cpmac0"). Stattdessen konfigurieren sie das Interface auf Treiberebene insgesamt so um, daß es alles mit der gesetzten VLAN ID 7 sendet. Ergo fühlt sich das IP-Interface des 300HS nicht mehr angesprochen, weil Dein Paket mit der Ziel-IP 192.168.1.99 mit einer VLAN ID 7 ankommt.

 

[Massa]

Das ist tatsächlich nicht so einfach. Im Originalthread bei Onlinekosten hat es auch noch keiner ohne vorgeschalteten Switch geschafft.

Ein vorgeschalteter Switch ist auch nicht das gelbe vom Ei, dann muss ich ja immer meinen Rechner sowohl an diesen Switch als auch (z.B. per WLAN) über den SP-701 anhängen (damit ein Internet-Verbindung besteht)

Bei mir scheitert das Eintragen per Webinterface mit einer Fehlermeldung ("200: Gateway IP unreachable" oder so).

Ja, das ist bei mir auch so - aber von Kommandozeile aus geht es
Da muss man dann nur noch herausfinden, wie es ins flash gespeichert werden kann, damit es einen Reboot "überlebt".

Ergo fühlt sich das IP-Interface des 300HS nicht mehr angesprochen, weil Dein Paket mit der Ziel-IP 192.168.1.99 mit einer VLAN ID 7 ankommt.

Bist Du sicher?
Ich dachte, die VLAN7 geht direkt per PPPOE über das Modem hin zum T-Com Verbindungspunkt.

Eine weiterer Gedanke war die Hoffnung, dass ich im SP701 ein weiteres virtuelles Interface anlegen könnte, das über die physikalische Schnittstelle eben ohne VLAN-Tagging kommuniziert.

Oder Könnte man es nicht im 300HS so einrichten, dass es sich für das VLAN7 "interessiert"?

Gruß,
Matthias

 

[frank_m24]

Hallo,

genau zu dem Thema gibts schon lange Diskussionen:

http://www.ip-phone-forum.de/showthread.php?t=167099

Ich hab mittlerweile herausgefunden, dass die Box keine IP-Pakete aufs WAN Interface durchlässt. Also keine Chance, jedenfalls nicht mit Boardmitteln. Vielleicht kann man mit iptables was machen.

 

[meyergru]

Bist Du sicher?
Ich dachte, die VLAN7 geht direkt per PPPOE über das Modem hin zum T-Com Verbindungspunkt.

Eine weiterer Gedanke war die Hoffnung, dass ich im SP701 ein weiteres virtuelles Interface anlegen könnte, das über die physikalische Schnittstelle eben ohne VLAN-Tagging kommuniziert.

Genau da liegt m.E. das Problem. Durch das Umschalten des Interfaces für LAN 1 (es ist übrigens "wan", siehe hier) auf VLAN-Modus wird jedes Paket, das über dieses Interface versendet wird, mit einem VLAN-Header ausgestattet. Und das Interface kann eben nur in einem Modus sein. Wäre das mit Linux-Bordmitteln realisiert, könnte man mehrere logische Interfaces definieren, die jeweils unterschiedlich arbeiten.

Wie es scheint, wird da aber ganz unabhängig vom VLAN-Modus schon was gefiltert, der von frank_m24 verlinkte Thread besagt zumindest, daß es auch bei Leuten mit einem Lucent Cellpipe 22A-BX-AR nicht geklappt hat und das verwendet sicher kein VLAN für PPPoE.

Entweder wird da die Firewall (iptables) aktiv oder der cpmac-Treiber filtert im "ata"-Modus selbst. Aber selbst, wenn man das Problem lösen könnte, wird das mit dem VLAN das nächste sein.

 

[frank_m24]

Hallo,

ich muss leider jetzt ins Bett, weil morgen muss ich ganz früh auf Dienstreise. Bin deshalb aber auch wohl morgen Abend nicht im Forum aktiv. Deshalb kann ich heute Abend leider keine Diskussion mehr lostreten.

Mich interessiert das Thema aber brennend. Nicht nur, um die Weboberfläche eines externen Modems direkt über die Box zu erreichen, sondern auch, weil ich denke, mit Hilfe von VLANs kann man vielleicht 2 PVCs über ein externes Modem aufbauen. In meinem Sphairon AR860 kann ich jedenfalls VPI/VCI Paare einrichten, die sich per VLAN Tags ansprechen lassen.

Insgesamt glaube ich, die beiden Probleme müssten lösbar sein. Sowohl der Zugriff auf die Weboberfläche als auch die Unterstützung für VLAN Tags (sei es für VDSL oder für 2 PVCs). Was haltet ihr davon, wenn wir die nächsten Tage mal ein bisschen koordinierte Forschungsarbeit da rein investieren? Mir schweben ein paar Ideen vor mit cpmac, iptables und 802.1q Unterstützung im Kernel, die man mal ausprobieren könnte.

bis denn

Frank

 

[meyergru]

Gibt es in dem Thema inzwischen Fortschritte? Ich habe das nochmal probiert und eth0 eine IP aus dem Bereich des Modems gegeben.

Auf der 7270 mit aktueller Firmware bekomme ich noch nicht einmal einen Ping beantwortet, von NAT oder Routing ganz zu schweigen.

Ich habe aber die Vermutung, daß das mit dem VLAN 7 zusammenhängt, weil ich ja VDSL habe. Bekommen Nicht-VDSL-Nutzer zumindest eine Ping-Antwort?

 

[frank_m24]

Hallo,

nein, ich weiß inzwischen, dass das WAN Interface durch die binaries von AVM komplett aus der IP-Kommunikation ausgeblendet wird. Selbst mit einer statischen Route im Modem bekommt man keine Antwort auf ein Ping - auch ohne VDSL.

 

[meyergru]

Aha. Weißt Du, wie AVM dann an die Infos zur Verbindungsgeschwindigkeit kommt? Ich meine diese hier:

Jul 12 14:26:17 dsld[1303]: voip: ppptarget voip disabled, ignored
Jul 12 14:26:17 dsld[1303]: PPP led: off (value=0)
Jul 12 14:26:17 dsld[1303]: speed 27616/5536 (LAN)
Jul 12 14:26:17 dsld[1303]: showtime
<6>kdsld: showtime
<6>kdsld: VCC 0: registered (wan)
Jul 12 14:26:17 dsld[1303]: PPPoEFW: need vlan 7 (behind VDSL modem)
<6>kdsld: dev_add_pack(pppoe)
<6>kdsld: dev_add_pack(vlan)
<6>kdsld: PPPoE forwarding for lan enabled.
<6>kdsld: PPPoEFW: VPI/VCI 0/0 on VLAN 7
Jul 12 14:26:17 dsld[1303]: internet: PPPoE VLAN autodetect disabled
<6>kdsld: 0: VPI/VCI 0/0 PPPoE internet 00:1c:4a:0f:83:ae (36,0) mc upstream
<6>kdsld: 0: on VLAN 7
<6>kdsld: 2: VPI/VCI 0/0 RBE mstv 00:1c:4a:0f:83:b0 (28,14) mc upstream
<6>kdsld: 2: on VLAN 8

Die Info muß doch vom VDSL-Modem kommen? Mir scheint nach der Initialisierung die PPPoEFW (PPPoE-Firewall?) erst die nicht benötigten Protokolle abzuschalten.

 

[MaxMuster]

Vielleicht kann man dazu ja mal etwas in die Firewall-Config in der ar7.cfg eingreifen???

Mögliche Ansatzpunkte:

        pppoefw {
                interfaces = "lan", "usbrndis", "eth0", "eth1", "wlan";
                nofirewall = yes;
                ipnetbiosfilter = yes;
                dnsfilter_for_active_directory = yes;
                hostuniq_filter = "";
                dpconfig {
                        security = dpsec_host;
                        lowinput {
                                [B]policy = "reject";[/B] <-- hier mal ein "permit" versuchen
                                accesslist =
                                             "permit ip any any connection outgoing-related",
                                             "permit ip any any connection incoming-related",
                                             "permit icmp any any";

[....]

        dslifaces {
                enabled = yes;
                name = "internet";
                dsl_encap = dslencap_inherit;
                dslinterfacename = "dsl";
                no_masquerading = no;
                [B]no_firewall = no;[/B] <-- hier mal ein "yes" versuchen
                pppoevlanauto = no;
                pppoevlanauto_startwithvlan = no;
                ppptarget = "internet";

Jörg

 

[meyergru]

Im Prinzip eine sehr gute Idee, wie gesagt, ich hätte sowieso keinen Erfolg damit, weil bei mir das VLAN 7 eingeschaltet ist. Das müßte jemand anderes probieren...

 

[frank_m24]

Hallo,

Im Prinzip eine sehr gute Idee, wie gesagt, ich hätte sowieso keinen Erfolg damit, weil bei mir das VLAN 7 eingeschaltet ist.

Das hat absolut gar nichts miteinander zu tun.

 

[meyergru]

Hallo,
Das hat absolut gar nichts miteinander zu tun.

So? Wenn es einen Weg gäbe, die Pakete durchzubekommen, würden Pings wegen des VLANs bei mir immer noch nicht beantwortet. Also wäre es Unfug, wenn ich das teste, weil ich es nicht mal merken würde, falls die erste Hürde tatsächlich durch irgendeinen Kunstgriff beseitigt wäre.

Oder mache ich da jetzt einen Denkfehler? Bislang hast Du ja noch nicht gesagt, was es heißt, "dass das WAN Interface durch die binaries von AVM komplett aus der IP-Kommunikation ausgeblendet wird". Werden IP-Pakete ohne PPPoE-Kapsel grundsätzlich gefiltert? Wie? Durch die PPPoEFW? Dann wäre der vorgeschlagene Ansatz ja prinzipiell nicht verkehrt.

 

[frank_m24]

Hallo,

Wenn es einen Weg gäbe, die Pakete durchzubekommen, würden Pings wegen des VLANs bei mir immer noch nicht beantwortet.

Was für eine Vorstellung hast du eigentlich von VLAN Tags in PPPOE Paketen?

Oder mache ich da jetzt einen Denkfehler?

Ja. Möglicherweise ist es auch ein grundsätzliches Verständnisproblem.

Werden IP-Pakete ohne PPPoE-Kapsel grundsätzlich gefiltert?

Ja.

Wie? Durch die PPPoEFW? Dann wäre der vorgeschlagene Ansatz ja prinzipiell nicht verkehrt.

Möglich. Ich konnte es selbst noch nicht testen.

 

[meyergru]

Was für eine Vorstellung hast du eigentlich von VLAN Tags in PPPOE Paketen?

Folgende:

VLAN Tags sind im wesentlichen Header in Ethernet-Paketen. Deren Bedeutung ist so, daß die nachfolgenden Bytes dann den eigentlichen Paketinhalt tragen. Somit kann man verschiedene "logische" LANs auf einem physischen Ethernet aufbauen.

PPPoE ist auch nur ein Header vor IP-Paketen. Beides sind Encapsulations.

Im Fall von VDSL werden die PPPoE-Frames noch in VLAN-Frames eingekapselt, d.h. das VDSL-Modem bzw. der dahinter stehende DSLAM/Access Controller reagiert nur auf PPPoE-Frames, die ihrerseits in VLAN-Frames mit der ID 7 eingekapselt sind. Das sieht dann so aus:

VLAN-Header PPPoE-Header IP-Header Nutzdaten

Wenn man nun im Router auf dem WAN-Interface wan0 die Kernel-eigenen Mechanismen zum Hinzufügen von VLAN-Headern benutzen würde, könnte man z.B. unter dem logischen Interface wan0.7 Pakete des o.a. Typs erzeugen, die dann vom VDSL-Modem als PPPoE-Frames aufgefaßt und verarbeitet werden. Alles andere wird verworfen.

Gleichzeitig könnte man aber unter dem physischen Interface wan0 aber noch "normale" IP-Pakete versenden, auf die das Modem unter der IP 192.168.1.99 reagiert, um an die Weboberfläche des Modems zu kommen.

Leider macht AVM das im VDSL-Betrieb aber so, daß sie das gesamte physische Interface wan0 komplett in den VLAN-Modus umschalten, so daß alle Ethernet-Pakete immer zwangsweise mit VLAN-Tags ausgestattet werden. Somit würden auch ausgesendete ICMP-Ping-Frames und IP-Frames mit VLAN-ID 7 gesendet und darauf reagiert der im Speedport 300HS integrierte TCP-IP-Stack (und der Webserver) eben nicht, völlig unabhängig davon, ob überhaupt IP-Pakete an irgendeiner Firewall im Router an das WAN-Interface gelangen. Deren Aufbau wäre dann so:

VLAN-Header IP-Header Nutzdaten

Das könnte ich die "Sperre" überwinden und bekäme trotzdem keinen Zugriff auf die Weboberfläche des Modems. Also bin ich kein besonders guter Tester für das grundsätzliche Problem.

Im Fall eines DSL-Modems, das kein VLAN benötigt, werden PPPoE-Frames und IP-Pakete auf der selben Schnittstelle ohne VLAN-Header übertragen, dort würde ein Modem, das auch eine Weboberfläche zur Abfrage von DSL-Parametern besitzt, eben antworten, wenn man überhaupt Pakete an das WAN-Interface senden kann.

Ja. Möglicherweise ist es auch ein grundsätzliches Verständnisproblem.

Glaube ich auch. Fragt sich nur bei wem? Ich lasse aber gern meine Vorstellung korrigieren, wenn sie nicht stimmt.

 

[frank_m24]

Hallo,

VLAN Tags sind im wesentlichen Header in Ethernet-Paketen.

Ich würde sie eher als eine Erweiterung des Ethernet Headers bezeichnen.

PPPoE ist auch nur ein Header vor IP-Paketen. Beides sind Encapsulations.

Na ja, so würde ich es nicht ausdrücken, auch wenn du wahrscheinlich das Richtige meinst.

Im Fall von VDSL werden die PPPoE-Frames noch in VLAN-Frames eingekapselt, d.h. das VDSL-Modem bzw. der dahinter stehende DSLAM/Access Controller reagiert nur auf PPPoE-Frames, die ihrerseits in VLAN-Frames mit der ID 7 eingekapselt sind.

Ich bin mir sehr sicher, dass es nur das Modem interessiert. Ab DSL werden die Daten über ATM VPI/VCI Paare gemultiplext. Dort haben VLAN Tags nichts mehr verloren.
Meines Erachtens hat man VLAN Tags in VDSL PPPOE nur eingeführt, um auch bei externen Modems multiple PVCs unterstützen zu können, z.B. Internet, VoIP und IP-TV. Auf DSL Ebene werden diese dann auf mehrere VPI/VCI Paare gemappt. Man macht das, weil die QoS und Multiplexer in ATM sehr viel leistungsfähiger sind, als in IP.

VLAN-Header PPPoE-Header IP-Header Nutzdaten

Ich würde eher sagen
Ethernet Header inkl. VLAN Tag - PPP Header - IP-Header - Nutzdaten.

Leider macht AVM das im VDSL-Betrieb aber so, daß sie das gesamte physische Interface wan0 komplett in den VLAN-Modus umschalten, so daß alle Ethernet-Pakete immer zwangsweise mit VLAN-Tags ausgestattet werden.

Bist du dir da sicher? Meines Wissens setzt AVM die VLAN Tags nicht über 802.1Q im Kernel, sondern selber im Closed Source Daemon. D.h., nicht sämtlicher Datenverkehr, sondern nur die PPPOE Frames hätten VLAN Tags. Das würde auch zu einigen Paketmitschnitten passen, die ich gesehen habe, und vor allem ließen sich so auch meine fehlgeschlagenen Versuche erklären, über VLAN Tags mehrere PVCs über ein externes Modem aufzubauen.

Übrigens: Beide Modifikationen in der ar7.cfg brachten bei mir keine Besserung. Ein DSL Modem an LAN1 war per IP nicht erreichbar.

 

[meyergru]

Ich bin mir sehr sicher, dass es nur das Modem interessiert. Ab DSL werden die Daten über ATM VPI/VCI Paare gemultiplext. Dort haben VLAN Tags nichts mehr verloren.
Meines Erachtens hat man VLAN Tags in VDSL PPPOE nur eingeführt, um auch bei externen Modems multiple PVCs unterstützen zu können, z.B. Internet, VoIP und IP-TV. Auf DSL Ebene werden diese dann auf mehrere VPI/VCI Paare gemappt. Man macht das, weil die QoS und Multiplexer in ATM sehr viel leistungsfähiger sind, als in IP.

Das ist gut möglich. Es gibt ja auch noch das VLAN 8, was bislang noch nicht genutzt wird (kann man aber im Diagnoseoutput der Fritzbox schon sehen). Das würde aber bedeuten, daß diese Logik schon von vornherein komplett festgelegt sein müßte (da m.W. das VDSL-Modem keinen automatischen Firmware-Update bekommt). T-Online könnte z.B. später nicht ohne weiteres die Zuordnungen ändern.

Ich würde eher sagen
Ethernet Header inkl. VLAN Tag - PPP Header - IP-Header - Nutzdaten.

Genau. Eigentlich ist VLAN keine Kapsel, sondern gemäß 802.1q/p ein Tag im Ethernet Header. Trotzdem werden solche Frames vom Stack verworfen, wenn man nicht speziell auf dieses VLAN lauscht.

Bist du dir da sicher? Meines Wissens setzt AVM die VLAN Tags nicht über 802.1Q im Kernel, sondern selber im Closed Source Daemon. D.h., nicht sämtlicher Datenverkehr, sondern nur die PPPOE Frames hätten VLAN Tags. Das würde auch zu einigen Paketmitschnitten passen, die ich gesehen habe, und vor allem ließen sich so auch meine fehlgeschlagenen Versuche erklären, über VLAN Tags mehrere PVCs über ein externes Modem aufzubauen.

Übrigens: Beide Modifikationen in der ar7.cfg brachten bei mir keine Besserung. Ein DSL Modem an LAN1 war per IP nicht erreichbar.

Nein, das schließe ich nur aus den Erfahrungen, die ich mit verschiedenen Versionen von Kernels und AVM-Boxen gemacht habe, als ich in dem anderen Thread mit anderen zusammen herausgefieselt habe, wie man VDSL mit einer Fritzbox hinbekommt.

Es hing tatsächlich mit "neuen cpmac-Treiber" zusammen, zumindest hat der Daemon darauf reagiert und Boxen, die den noch nicht hatten, konnten es definitiv nicht. Da wurde zumindest klar, daß es nicht per Kernel gemacht wurde, sondern vom Treiber unterstützt werden muß. Das erschien mir damals ähnlich zur Vorgehensweise bei Windows, wo VLAN auch zuerst nur von einigen NIC-Treibern unterstützt wurde. Das geht natürlich auch anders, indem der Treiber die Raw-Packets selbst baut.

Ich weiß auch, daß der Daemon zumindest die Umschaltung selbst steuert, weil er offensichtlich erst ohne VLAN und dann mit testet (man sieht so etwas in der Art in den Logs). Daß er dann einfach das Interface auf den VLAN 7 schaltet, habe ich nur vermutet.


Was mir nicht ganz klar ist: Es gibt ja ein Ethernet-Interface, das der Daemon steuert. Wieso kann man mit dem normalen IP-Stack nicht Pakete darauf absenden (Dein Test zeigt das ja)? Steuert der Daemon das Interface in einen exklusiven Modus?

Normalerweise, z.B. wenn man sich so etwas wie den Roaring Penguin PPPoE ansieht, wird ja einfach das Interface raw angesteuert, aber parallel dazu kann man es immer noch normal über den IP-Stack verwenden.

 

[MaxMuster]

Zwei Dinge dazu:
1. "Haut" euch doch nicht, es geht doch um die gute Sache und ihr habt doch beide Ahnung!

2. Ich denke, AVM greift ziemlich tief auch in die Treiber ein. Meine Versuche, die "alten" Boxen (meine Eumex) mit VLAN-Fähigkeit auszustatten haben nicht so einfach funktioniert (ist schon etwas her, daher nur Fehlermeldungen aus dem Kopf). Der CPMAC Treiber hat entweder rausgehnde Pakete mit VLAN-ID verworfen ("Interface spricht VLAN, obwohl es das nicht darf") oder, nachdem ich da ein wenig herumgeptched hatte, die eingeheneden Pakete mit sinngemäß genau gegenteiliger Begründung). Einige der VLAN-relevanten Befehle waren auch nur im Switch-Treiber zu finden, vermutlich kann zumindest das "alte" Interface so kein echtes VLAN sondern nur die oben genannte "Krücke" einen VLAN-Header davorzusetzen beziehungsweise abzustreifen....

Jörg

EDIT Etwas habe ich noch gefunden: Beim Senden im VLAN, das per "vconfig add" angelegt wurde sieht das dann so aus:

[cpmac] cpmac_main_dev_send, drop vlan pkt (46 bytes)
[cpmac] cpmac_main_dev_send, drop, 1, 0
[cpmac] [cpphy_if_tx_complete] 46 bytes dropped (9)

 

[frank_m24]

Hallo,

ich frage mich gerade, wie das wohl auf der anderen Seite implementiert wird. Weil: Stellen wir uns doch mal vor, wie das in der Box realisiert ist.

Da ist ein Switch-Baustein, der wahrscheinlich 5 Ports hat: 4 führen nach außen, 1 dürfte an den Controller angeschlossen sein. Wenn man nun mit port-based VLANs arbeitet (mit deren Hilfe AVM ja "Internet über LAN 1" realisiert), dann passiert das üblicherweise mit VLAN Tags auf dem 5., internen Anschluss. Mit anderen Worten: Die virtuellen Ethernet Interfaces (eth0, eth0:1 ...), die hinterher auf den separaten Switch-Ports landen, werden per VLANs über den einzelnen Anschluss zum Controller getrennt. Wie soll man es auch sonst machen?

Also: Um überhaupt den einen LAN Port, an dem das externe Modem hängt, gezielt ansprechen zu können, muss man auf dem Interface zwischen Controller und Switch schon mit VLAN Tags arbeiten. Und nun braucht man zusätzlich noch VLAN Tags für den Datenstrom, der aus diesem Port rauskommt. Kaskadierte VLAN Tags geht aber meines Wissens nicht. Wie also realisiert man das? Ist der Switch-Baustein intelligent genug, z.B. eine interne VLAN ID 17 auf den ersten LAN Port in VLAN ID 7 umzuwandeln, und z.B. eine interne ID 18 auf den ersten Port als VLAN 8? Oder werden da doch irgendwo Ethernet Frames manuell zusammengebaut?

Aber was heißt das jetzt für unsere Ziele? Immerhin verfolge ich momentan zwei Ziele: Zum einen möchte ich irgendwann ein externes Modem per IP erreichen können, zum anderen möchte ich zwei PVCs über ein externes Modem benutzen. Für letzteres bleiben mir wahrscheinlich nur VLAN Tags, ich wüsste jedenfalls nicht, wie ich sonst die Datenströme zum Modem differenzieren könnte. Mehrere Modems, z.B. ein AR860 oder Thomson Speedtouch Geräte, können so konfiguriert werden, dass sie mehrere PVCs über VLANs getrennt zur Verfügung stellen.

 

[MaxMuster]

Also: Um überhaupt den einen LAN Port, an dem das externe Modem hängt, gezielt ansprechen zu können, muss man auf dem Interface zwischen Controller und Switch schon mit VLAN Tags arbeiten. Und nun braucht man zusätzlich noch VLAN Tags für den Datenstrom, der aus diesem Port rauskommt.

Welchen "Datenstrom" meinst du? Falls der "externe" Port getagged ist?
Entweder könntest du das VLAN doch "intern" genauso wie auch nach draußen wählen, oder (denn eindeutig müssen dei doch eh sein)? Oder aber ich könnte sie untagged rausgeben, quasi als "Accessports" im VLAN.

Jörg
Edit Link zum ADM9669 leider nur "sehr oberflächlich" (das müsste doch der Switch-Baustein sein??)
EDIT2 aus "cpphy_adm6996.c"

/*------------------------------------------------------------------------------------------*\
 * default VLAN setting
 * port 0~3 as untag port and PVID = 1
 * VLAN1: port 0~3 and port 5 (MII)
\*------------------------------------------------------------------------------------------*/