TP-Link CPE210/510

Ich habe eine Frage zum Kaskadieren.

Folgendes Setup: CPE210 #1 normal per POE Adapter und von dort aus am Kabelmodem angeschlossen. Nun soll ein zusätzlicher CPE210 #2 dazu kommen, der über den zweiten Anschluss am CPE210 #1 mit POE versorgt werden soll. Das klappt soweit.

Hier ein Diagramm:

Nun soll der CPE210 #2 aber einen eigenständigen VPN Uplink bekommen und sich nicht sein Internet über ein Mesh per LAN/WAN oder WLAN holen.

Weiß spontan jemand, wie das zu realisieren ist?

Mesh-on WAN aus
Mesh-on-VPN an

aber WOZU???

Wenn dein Uplink Router VLAN unterstützt, könntest du bei den beiden CPE210 durch manuelle Einstellungen zum gewünschten Ergebnis kommen. Oder du setzt zwischen Uplink und POE Injector noch einen günstigen OpenWRT Router für die VLAN, zB einen 740 oder 841.

Ich glaube ihr versteht noch nicht ganz, worum es mir geht: Ich möchte, dass der CPE210 #2 genauso wie #1 eine IP vom Kabel-Modem bezieht und damit einen eigenen VPN-Uplink zum Freifunk-Netz bekommt.

Ansonsten hängt #2 an dem VPN-Uplink von #1 und der muss dann die ganze Arbeit für die VPN-Verschlüsselung übernehmen. Hätten beide getrennte Uplinks, wären beide CPUs gleich belastet.

Mir geht’s also nur darum, dass #1 über seinen zweiten LAN-Port das Netz vom WAN-Port bridged.

Bekommt er in jedem Fall

Ja, und die Supernodes, die eh schon aus dem letzten Loch pfeifen werden unnötig durch zusätzliche VPN-Tunnel mehr belastet.
Die CPU/RAM-Kombi in den CPEs reicht locker für nen halbes Dutzend Router aus.

Sorry, aber das ist einfach Quatsch!

In der Standardkonfiguration des CPE210 fällt aus dem 2. Ethernet Port das Client Netz raus.
Du musst also den Switch Port 5 aus der Bridge br-client herausnehmen, dann die interne VLAN ID 2 löschen, den freigewordenen Switch Port 5 dem VLAN 1 zuordnen und danach dann der Bridge br-wan.

Das könnte klappen, ist allerdings niemals nicht getestet, ohne Gewähr und wohl auch nicht sinnvoll. Die CPU der CPE210 sollte eigentlich stark genug sein, die Rechenlast zu bewältigen.

1 „Gefällt mir“

[quote=„Freigraf, post:86, topic:594, full:true“]
In der Standardkonfiguration des CPE210 fällt aus dem 2. Ethernet Port das Client Netz raus.Du musst also den Switch Port 5 aus der Bridge br-client herausnehmen, dann die interne VLAN ID 2 löschen, den freigewordenen Switch Port 5 dem VLAN 1 zuordnen und danach dann der Bridge br-wan.[/quote]
Super, das hilft mir doch gleich weiter. Vielen Dank fürs erläutern!

Ich denke Probieren geht über Studieren. Wenn das bisher noch niemand gemacht hat, probier ich es gerne mal aus und berichte dann, obs geklappt hat :slight_smile:

PS: Hintergrund, warum beide CPEs einen eigenen VPN-Uplink haben sollen: Sie hängen an einem sehr zentralen Punkt direkt in der Innenstadt und leuchten jeweils eine Richtung der Einkaufsstraße aus. Zu Stoßzeiten hat CPE #1 bereits jetzt um die 15-20 Clients.

Möglicherweise überstehen die Änderungen das nächste Update nicht. Wäre es nicht das beste, beide CPE210 einfach getrennt und eigenständig zu verkabeln, mit zwei POE-Netzteilen und zwei Ethernetkabeln? Ich mein ja nur… :wink:

Ist das bestätigt?
Zumindest war ich bislang davon ausgegangen, dass dort „nur“ geswitched das WAN (also die erste Buchse) ansteht.

Wenn nicht, dann sollte meiner Meinung nach geändert werden im Gluon, weil es schlicht anders keinen Sinn ergibt.
(Sofern nicht jemand eine Überwachungskamera in Mastmontage ins Freifunk-Netz hängen will auf dieser Weise. Dürfte aber nicht so die Standard-Anwendung sein im Vergleich zu „Zwei Freiunk-Router an einem Mast“)

[quote=„adorfer, post:89, topic:594“]
Ist das bestätigt? Zumindest war ich bislang davon ausgegangen, dass dort „nur“ geswitched das WAN (also die erste Buchse) ansteht.[/quote]
Ich ging auch davon aus, das der WAN einfach weitergereicht wird. Welche Interface-Daten brauchst du? Kann gerne nachschauen.

[quote=„adorfer, post:89, topic:594“]
Wenn nicht, dann sollte meiner Meinung nach geändert werden im Gluon, weil es schlicht anders keinen Sinn ergibt. (Sofern nicht jemand eine Überwachungskamera in Mastmontage ins Freifunk-Netz hängen will auf dieser Weise. Dürfte aber nicht so die Standard-Anwendung sein im Vergleich zu „Zwei Freiunk-Router an einem Mast“)[/quote]
Genau so sehe ich das auch. Damit wäre mein Problem auch schon sofort erledigt.

mach doch mal nen pastebin von ‚uci show network‘

# brctl show
bridge name     bridge id               STP enabled     interfaces
br-client       7fff.e8de27cebdd4       no              eth0.2
                                                        bat0
                                                        wlan0-1
br-wan          7fff.eadf27cebdd4       no              eth0.1



# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
Port 0:
        pvid: 0
        link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
Port 1:
        pvid: 0
        link: port:1 link:down
Port 2:
        pvid: 0
        link: port:2 link:down
Port 3:
        pvid: 0
        link: port:3 link:down
Port 4:
        pvid: 2
        link: port:4 link:down
Port 5:
        pvid: 1
        link: port:5 link:up speed:100baseT full-duplex auto
VLAN 0:
        vid: 0
        ports: 0t 1 2 3
VLAN 1:
        vid: 1
        ports: 0t 5
VLAN 2:
        vid: 2
        ports: 0t 4

Am zweiten Port ist hier nichts angeschlossen, deshalb „Port 4 down“

Was wieder bedeutet, das im Expert Modus am besten eine Switch Konfiguration eingebaut werden sollte um bei diesen Geräten wählen zu können ob der Anschluss mit WAN gebridged werden soll oder nicht.

Bitteschön: http://pastebin.com/0EnA2kNf

Meiner Meinung nach (und den Unfällen der letzten Wochen, siehe auch aktuellen Störungsthread Ruhrgebiet und dem letzten im Rheinufer) sollte „BRclient“ an den LAN-Buchsen per Default AUS gestellt werden und nur unter irgendeinem kryptischen Namen in der Expert-Config erreichbar sein. An ALLEN Freifunk-Routern.

3 „Gefällt mir“

Hier noch meine Ausgaben von brctl und swconfig:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br-client       7fff.14cc204744ea       no              bat0
                                                        wlan0-1
br-wan          7fff.16cd204744ea       no              eth0.1
 
# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
Port 0:
        pvid: 0
        link: port:0 link:up speed:1000baseT full-duplex txflow rxflow 
Port 1:
        pvid: 0
        link: port:1 link:down
Port 2:
        pvid: 0
        link: port:2 link:down
Port 3:
        pvid: 0
        link: port:3 link:down
Port 4:
        pvid: 2
        link: port:4 link:up speed:100baseT full-duplex auto
Port 5:
        pvid: 1
        link: port:5 link:up speed:100baseT full-duplex auto
VLAN 0:
        vid: 0
        ports: 0t 1 2 3 
VLAN 1:
        vid: 1
        ports: 0t 5 
VLAN 2:
        vid: 2
        ports: 0t 4

EDIT: Bei mir fehlt wohl die Brücke zu eth0.2, weil ich mit Mesh-on-LAN rumexperimentiert hatte.

Da stimme ich zu. Der Schaden überwiegt den Nutzen momentan.

Eine Auswahlmöglichkeit in der Config sollte die Poweruser zufrieden stellen.

2 „Gefällt mir“

So, ich habe den Vorschlag von @Freigraf jetzt mal ausprobiert. Aktuell sieht es so aus:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br-wan          7fff.16cd204744ea       no              eth0.1
                                                        eth0.2
br-client       7fff.14cc204744ea       no              bat0
                                                        wlan0-1

# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
Port 0:
        pvid: 0
        link: port:0 link:up speed:1000baseT full-duplex txflow rxflow 
Port 1:
        pvid: 0
        link: port:1 link:down
Port 2:
        pvid: 0
        link: port:2 link:down
Port 3:
        pvid: 0
        link: port:3 link:down
Port 4:
        pvid: 1
        link: port:4 link:up speed:100baseT full-duplex auto
Port 5:
        pvid: 1
        link: port:5 link:up speed:100baseT full-duplex auto
VLAN 0:
        vid: 0
        ports: 0t 1 2 3 
VLAN 1:
        vid: 1
        ports: 0t 4 5 
VLAN 2:
        vid: 2
        ports: 0t

Sieht also genauso aus, wie gedacht. Allerdings funktioniert es nicht. Sprich: CPE #2 erhält keine IP-Adresse und mesht weiterhin über WLAN.

Was mich doch etwas verwundert: VLAN 2 hatte ich über die uci Kommandos gelöscht, aber es taucht trotzdem noch auf?

Jemand noch eine Idee?

Am VLAN 2 ist nur noch Port 0 verbunden, das ist der virtuelle Port der CPU.

Ok, ich habs endlich hinbekommen :grinning:

Der Grund warum es nicht geklappt hat:

Ich hatte eth0.2 in die Brücke br-wan getan. Mir war nicht bewusst, das eth0.1 und eth0.2 keine echten Interfaces sind, sondern nur VLANs. eth0.1 ist VLAN1 und eth0.2 VLAN 2. Damit habe ich beide VLANs zusammengebrückt, was natürlich absoluter Käse war :smile:

Hier die nötigen Schritte, um das Netz am WAN-Port eines CPE210 an dessen Secondary LAN-Port weiter zu reichen. Der an den Secondary LAN-Port angeschlossene, zweite CPE210 nutzt dann den gleichen Uplink und bekommt eine eigene IP-Adresse vom Router/Modem zugeteilt und kann sich somit auch seinen eigenen VPN-Uplink zu einem Supernode aufbauen:

# eth0.2 aus dem Client Netz nehmen
uci set network.client.ifname='bat0'

# VLAN 2 löschen
uci delete network.@switch_vlan[1]

# VLAN 1 den freigegeben Port 4 (LAN) zuweisen
uci set network.@switch_vlan[0].ports='0t 4 5'

uci commit network
/etc/init.d/network restart

Danke auf jeden Fall an @Freigraf für den entscheidenden Tipp!

3 „Gefällt mir“