26
PfSense Hauptsubnet langsam und VLAN sehr schnell
Hallo
Ich versuche mal mein Problem zu beschreiben.
Ich habe eine pfsense am laufen.
192.168.1.0/24 ist das Hauptsubnet worüber das gesamte Lan läuft.
Rechner hängen via Kabel daran es gibt Wlan Bridges für entferntere Accesspoints.
Wlan wird über Ubiquiti Unifi realisiert.
Mein Hauptsubnet mit dem Home Wlan
Dann gibt es noch 192.168.10.0/24, 192.168.20.0/24 und 192.168.30/24, welche jeweils als VLAN tag zur pfsense kommen und die verschiedenen SSIDs der Unifis arbeiten damit.
So kann ich in der Firewall den Gruppen unterschiedliche Rechte zuweisen.
Soweit so gut.
Ich habe leide rnur eine Telekom Hybrid Leitung, also nicht den Mörderbums, jedoch ist mir schon länger aufgefallen, dass beispielweise Androis Updates im Heimnetz extrem langsam sind.
Downloadraten von 600 Kilobyte/s, mehr kommt da nicht rüber.
Da ich gerade was am 30er Wlan teste, habe ich mein tablet mal damit getestet.
Im Heimnetz besagte 600 Kilobyte/s und im 30er Subnet 4 Megabyte/s. Wechsel ich, habe ich jewiels die anderen Geschwindigkeiten.
Ich würde da eher auf die pfsense tippen, jedoch ist kein Traffic Shaping aktiv.
Ich hatte mal Squid drauf, hatte das meine ich sogar aktiviert, jedoch ist es deinstalliert.
Wo kann ich da noch schauen um den Fehler einzukreisen und letztendlich auzumerzen?
Ich versuche mal mein Problem zu beschreiben.
Ich habe eine pfsense am laufen.
192.168.1.0/24 ist das Hauptsubnet worüber das gesamte Lan läuft.
Rechner hängen via Kabel daran es gibt Wlan Bridges für entferntere Accesspoints.
Wlan wird über Ubiquiti Unifi realisiert.
Mein Hauptsubnet mit dem Home Wlan
Dann gibt es noch 192.168.10.0/24, 192.168.20.0/24 und 192.168.30/24, welche jeweils als VLAN tag zur pfsense kommen und die verschiedenen SSIDs der Unifis arbeiten damit.
So kann ich in der Firewall den Gruppen unterschiedliche Rechte zuweisen.
Soweit so gut.
Ich habe leide rnur eine Telekom Hybrid Leitung, also nicht den Mörderbums, jedoch ist mir schon länger aufgefallen, dass beispielweise Androis Updates im Heimnetz extrem langsam sind.
Downloadraten von 600 Kilobyte/s, mehr kommt da nicht rüber.
Da ich gerade was am 30er Wlan teste, habe ich mein tablet mal damit getestet.
Im Heimnetz besagte 600 Kilobyte/s und im 30er Subnet 4 Megabyte/s. Wechsel ich, habe ich jewiels die anderen Geschwindigkeiten.
Ich würde da eher auf die pfsense tippen, jedoch ist kein Traffic Shaping aktiv.
Ich hatte mal Squid drauf, hatte das meine ich sogar aktiviert, jedoch ist es deinstalliert.
Wo kann ich da noch schauen um den Fehler einzukreisen und letztendlich auzumerzen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 392424
Url: https://administrator.de/contentid/392424
Printed on: April 18, 2024 at 21:04 o'clock
26 Comments
Latest comment
Moin,
was für pakages wurden installiert?
Gibt es Priorisierungen?
Gruß
Spirit
was für pakages wurden installiert?
Gibt es Priorisierungen?
Gruß
Spirit
Hast du mal getestet ob das Problem wirklich extern ist oder auch Intern auftritt?
Tipp dazu: es gibt ein Iperf Package
Tipp dazu: es gibt ein Iperf Package
Nur nochmal damit wir dich nicht missverstehen WIE dein Port an der pfSense konfiguriert ist:
Die Einrichtung hast du exakt nach diesem Tutorial umgesetzt ?!:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Technisch kann das so nicht möglich sein was du beschreibst wenn man alles richtig konfiguriert hat. Logisch, denn VLANs und auch das Parent (native) Interface rennt ja immer über die gleiche Physik wenn du es so wie oben im Tutorial konfiguriert hast.
Autonegotiation Probleme am Port kann man ja auch ausschliessen, denn sonst wären natürlich alle Interfaces betrioffen, physische wie virtuelle die auf dem physischen liegen.
Sinnfrei ist natürlich immer einen Durchsatz Test via WLAN zu machen, da du die HF und Störungssituation niemals einschätzen kannst.
Es macht also Sinn mal einen Kupferport als Access Port (untagged) in eins oder alle VLANs zu setzen am VLAN Switch und DORT via Kabel mal einen Durchsatztest zu machen.
- Das Tagged Interface ist dein LAN Port an der pfSense
- Das Native (Parent) Interface ist das was untagged auf dem LAN Port liegt mit der IP 192.168.1.x /24
- Auf diesem physischen Parent Interface liegen auch deine virtuellen VLAN Interfaces für (vermutlich) VLANs 10, 20 und 30 ?
- Die virtuellen Interfaces haben dann IPs in den o.g. VLAN Subnetzen
Die Einrichtung hast du exakt nach diesem Tutorial umgesetzt ?!:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Technisch kann das so nicht möglich sein was du beschreibst wenn man alles richtig konfiguriert hat. Logisch, denn VLANs und auch das Parent (native) Interface rennt ja immer über die gleiche Physik wenn du es so wie oben im Tutorial konfiguriert hast.
Autonegotiation Probleme am Port kann man ja auch ausschliessen, denn sonst wären natürlich alle Interfaces betrioffen, physische wie virtuelle die auf dem physischen liegen.
Sinnfrei ist natürlich immer einen Durchsatz Test via WLAN zu machen, da du die HF und Störungssituation niemals einschätzen kannst.
Es macht also Sinn mal einen Kupferport als Access Port (untagged) in eins oder alle VLANs zu setzen am VLAN Switch und DORT via Kabel mal einen Durchsatztest zu machen.
Vielen Dank für Eure Antworten.
Pakete sind keine wilden installiert, nur NUT für die USV, was aber egal sein sollte, Openvpn
LightSquid habe ich da gerade noch gesehen, aber ohne Squid?
Ich weiß auch nicht ob ich Squid damals was eingestellt habe, jedenfalls hatte ich es mal herunter gehauen, da ich dachte das liegt an der Bremse.
Jetzt habe ich durch Zufall entdeckt, dass es nur das Hauptsubnet betrifft.
Es sind auch keine Priorisierungen aktiv und wenn dann sollte das im privaten Netz abends nicht so viel ausmachen.
Mein Lan1 ist em0 und darauf läuft die 192.168.1.x/24
Subnetze 10.x etc entsprechend dem VLAN laufen getagged dort mit auf.
Die Router IP ist dann jeweils eingetragen. 192.168.1.2 Haupt und dann entsprechend 192.168.10.2 etc und es ist jeweils der DHCP an.
Funktionieren tut das ja alles und es wurde auch nach der verlinkten Anleitung eingerichtet.
Der Tipp mit dem Vlan kam sogar von aqui und spart Ports am Switch. Im nächsten Ausbau werde ich Lan1 einzeln haben und dden Vlans Lan2 geben, aber das ist halt nur in Planung und gerade nicht interessant.
Ja, ich weiß Wlan ist nie Aussagekräftig, aber da fiel es mir als erstes auf. Der Kanal ist bei allen SSIDs ja auch der selbe und die Tests sind ja wirklich im Wechsel passiert indem ich immer die Wlans gewechselt habe am Handy. Wir reden ja auch nicht von kleinen Schwankungen, sondern von einer Steigerung um das 7 fache.
Am TestAP war im 30er Subnet aber nur mein handy eingeloggt und im 1er Subnet 5 Geräte welche alledings nicht aktiv waren.
Abbruch kann es doch aber nicht geben, weil im 1er Subnet sich die Switche und Mikrotik SXT als Bridges mit befinden, oder?
Da muss ich sowieso mal schauen, im Tut steht etwas von Mikrotik hat sich geändert, das habe ich wohl gesehen und Vlan 30 geht nicht sauber über die Bridges obwohl identisch eingerichtet wie die 10er, aber das schaue ich mir jetzt gleich erstmal in Ruhe an.
Edit:
Meinen Rechner habe ich eben mal das Subnet 10 zugewiesen (ungetagged) und da lies sich der Fehler nicht reproduzieren.
Beide Male 1,5 Megabyte/s, wobei das langsamere jetzt wohl dem Hybrid geschuldet sein wird.
Pakete sind keine wilden installiert, nur NUT für die USV, was aber egal sein sollte, Openvpn
LightSquid habe ich da gerade noch gesehen, aber ohne Squid?
Ich weiß auch nicht ob ich Squid damals was eingestellt habe, jedenfalls hatte ich es mal herunter gehauen, da ich dachte das liegt an der Bremse.
Jetzt habe ich durch Zufall entdeckt, dass es nur das Hauptsubnet betrifft.
Es sind auch keine Priorisierungen aktiv und wenn dann sollte das im privaten Netz abends nicht so viel ausmachen.
Mein Lan1 ist em0 und darauf läuft die 192.168.1.x/24
Subnetze 10.x etc entsprechend dem VLAN laufen getagged dort mit auf.
Die Router IP ist dann jeweils eingetragen. 192.168.1.2 Haupt und dann entsprechend 192.168.10.2 etc und es ist jeweils der DHCP an.
Funktionieren tut das ja alles und es wurde auch nach der verlinkten Anleitung eingerichtet.
Der Tipp mit dem Vlan kam sogar von aqui und spart Ports am Switch. Im nächsten Ausbau werde ich Lan1 einzeln haben und dden Vlans Lan2 geben, aber das ist halt nur in Planung und gerade nicht interessant.
Ja, ich weiß Wlan ist nie Aussagekräftig, aber da fiel es mir als erstes auf. Der Kanal ist bei allen SSIDs ja auch der selbe und die Tests sind ja wirklich im Wechsel passiert indem ich immer die Wlans gewechselt habe am Handy. Wir reden ja auch nicht von kleinen Schwankungen, sondern von einer Steigerung um das 7 fache.
Am TestAP war im 30er Subnet aber nur mein handy eingeloggt und im 1er Subnet 5 Geräte welche alledings nicht aktiv waren.
Abbruch kann es doch aber nicht geben, weil im 1er Subnet sich die Switche und Mikrotik SXT als Bridges mit befinden, oder?
Da muss ich sowieso mal schauen, im Tut steht etwas von Mikrotik hat sich geändert, das habe ich wohl gesehen und Vlan 30 geht nicht sauber über die Bridges obwohl identisch eingerichtet wie die 10er, aber das schaue ich mir jetzt gleich erstmal in Ruhe an.
Edit:
Meinen Rechner habe ich eben mal das Subnet 10 zugewiesen (ungetagged) und da lies sich der Fehler nicht reproduzieren.
Beide Male 1,5 Megabyte/s, wobei das langsamere jetzt wohl dem Hybrid geschuldet sein wird.
Ja, ich weiß Wlan ist nie Aussagekräftig,
Und warum testest du es denn nicht schlicht und einfach mal mit einem Kabel in jedem VLAN ??Ein Port am Switch ist ja in jedem VLAN mit einem simplen Mausklick erstellt....
Stimmt die VLAN Installation hat sich ab Router OS Version 6.41 grundlegend verändert. Siehe hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Das habe ich, siehe Edit.
Zumindest mit vlan 10.
Aber Hybrid ist auch schwankend.
Zu der Zeit kam es aber konstant. War eine Linux Distri als Test.
Morgen teste ich noch mal mit allen Subnets.
Zumindest mit vlan 10.
Aber Hybrid ist auch schwankend.
Zu der Zeit kam es aber konstant. War eine Linux Distri als Test.
Morgen teste ich noch mal mit allen Subnets.
So, nun habe ich noch mal etwas getestet.
Wie gesagt es ist eine Hybridleitung und die Rate schwankt da gerne mal, aber es kommt immer über 1 Megabyte/s an
Ich habe mein Rechner getestet und ihn ins entsprechende Vlan verwiesen.
192.168.1.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
192.168.10.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
192.168.30.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
Also am Rechner wirkt sich das nicht aus.
Dann probierte ich die Wlan Geschichte weiter. Dies mit 2 Geräten, Smartphone und Tablet.
192.168.1.x jetzt Nachmittags 0,6 Mbit wie gestern auch limitiert.
192.168.10.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
192.168.30.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
Das 20er Subnet habe ich wegen dem Captive Portal ausgelassen, es sollte aber auch so aussagekräftig sein.
Dann habe ich einem Unifi AccessPoint mein Heimnetz (192.168.1.x) temporär auf Vlan10 gelegt, wodurch ich auch im 10er Subnet wieder die schnelleren raten hatte.
Ich dachte zuerst an eine Limitierung seitens Unifi, was auch eingestellt werden kann, aber pro SSID und nicht auf das Vlan gemünzt.
Die SSID blieb ja identisch, nur das Vlan wurde umgestellt.
Wie gesagt es ist eine Hybridleitung und die Rate schwankt da gerne mal, aber es kommt immer über 1 Megabyte/s an
Ich habe mein Rechner getestet und ihn ins entsprechende Vlan verwiesen.
192.168.1.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
192.168.10.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
192.168.30.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
Also am Rechner wirkt sich das nicht aus.
Dann probierte ich die Wlan Geschichte weiter. Dies mit 2 Geräten, Smartphone und Tablet.
192.168.1.x jetzt Nachmittags 0,6 Mbit wie gestern auch limitiert.
192.168.10.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
192.168.30.x jetzt Nachmittags 1,5 Megabyte/s schwankend halt, teilweise mehr.
Das 20er Subnet habe ich wegen dem Captive Portal ausgelassen, es sollte aber auch so aussagekräftig sein.
Dann habe ich einem Unifi AccessPoint mein Heimnetz (192.168.1.x) temporär auf Vlan10 gelegt, wodurch ich auch im 10er Subnet wieder die schnelleren raten hatte.
Ich dachte zuerst an eine Limitierung seitens Unifi, was auch eingestellt werden kann, aber pro SSID und nicht auf das Vlan gemünzt.
Die SSID blieb ja identisch, nur das Vlan wurde umgestellt.
Ich habe das hier mal an einer pfSense (APU Hardware) exemplarisch in einem Testaufbau getestet. Allerdings nur auf einer Ethernet Infrastruktur.
Mit iPerf und NetIO erzielt man hier, wie vermutet, sowohl auf dem Parent als auch auf dem virtuellen VLAN Interface Wirespeed ohne jegliche Einschränkung.
Das schliesst eine ggf. vermutete HW Limitierung sicher aus. (Software natürlich auch !)
Die Schwankungen können bei dir also dann nur vom WAN selber kommen.
Mit iPerf und NetIO erzielt man hier, wie vermutet, sowohl auf dem Parent als auch auf dem virtuellen VLAN Interface Wirespeed ohne jegliche Einschränkung.
Das schliesst eine ggf. vermutete HW Limitierung sicher aus. (Software natürlich auch !)
Die Schwankungen können bei dir also dann nur vom WAN selber kommen.
Danke für den Test.
Es ist halt merkwürdig.
Ich verbinde mit dem selben Endgerät nachts, wo am WAN mehr ankommt abwechselnd und lade Updates über den Playstore von Google.
Heimnetz max 0,6MB, Umbuchung in anderes VLAN alles was geht, Umbuchung Heimnetz max 0,6MB und das unmittelbar hintereinander.
Ich habe auch schon geschaut ob etwas in den Unifis limitiert ist, ist es aber nicht.
Anzahl der Endgeräte im heimnetz (alles noch überschaubar) ist doch da auch nicht von belang, oder???
An den Speedport (geht ja nun nicht anders) kommt durch die PFSense ja auch nichts anderes an, sprich Vlans etc.
Es ist halt merkwürdig.
Ich verbinde mit dem selben Endgerät nachts, wo am WAN mehr ankommt abwechselnd und lade Updates über den Playstore von Google.
Heimnetz max 0,6MB, Umbuchung in anderes VLAN alles was geht, Umbuchung Heimnetz max 0,6MB und das unmittelbar hintereinander.
Ich habe auch schon geschaut ob etwas in den Unifis limitiert ist, ist es aber nicht.
Anzahl der Endgeräte im heimnetz (alles noch überschaubar) ist doch da auch nicht von belang, oder???
An den Speedport (geht ja nun nicht anders) kommt durch die PFSense ja auch nichts anderes an, sprich Vlans etc.
Selbst mit IDS/IPS habe ich da keine Probleme auf nem APU.
Oder hast du Traffic Shaper aktiv?
Oder hast du Traffic Shaper aktiv?
Nein habe ich nicht.
Ich meine sogar getestet zu haben auf einem AP das Heimnetz und Vlan zu stecken und es war schnell.
Im UNIFI habe ich die VLans sogar limitiert, aber das Heimnetz ist offen.
Vielleicht sollte ich da mal alles raus nehmen
Ich meine sogar getestet zu haben auf einem AP das Heimnetz und Vlan zu stecken und es war schnell.
Im UNIFI habe ich die VLans sogar limitiert, aber das Heimnetz ist offen.
Vielleicht sollte ich da mal alles raus nehmen
Nabend.
Ich möchte das Thema noch mal aufgreifen.
Ich versuche mir auf den Umstand einen Reim zu machen.
Liegt es vielleicht an den im Subnet liegenden Bridges?
Ich habe für entferntere AccessPoints Mikrotik SXTs als Bridge eingerichtet. Diese haben (aktuell noch) das Subnet vom Heimnetz.
Ich weiß man sollte dafür andere Subnetze nutzen. Transfernetz usw.
Demnächst stelle ich auf Ubiquiti um, da ich damit besser klar komme als mit den SXTs.
Aber davon ab, kann es daran liegen und wenn ja, wieso?
Wie stellt man das prinzipiell an mit den extra Subnets?
Ich erstelle beispielsweise 10.10.10.X und vergebe da die IPs für die SXTs.
Dann ein Vlan in der pfsense für genau selbiges Subnet und der Freigabe vom Homnet dahinein.
Also Heimnetz, SXT Bridge <-> SXT Bridge, AccessPoint oder Switche welche mit den Subnetzen wieder etwas anfangen können oder wie?
Da ist Vlan 1 für das Heimnetz aber kaum noch möglich oder??
Ich möchte das Thema noch mal aufgreifen.
Ich versuche mir auf den Umstand einen Reim zu machen.
Liegt es vielleicht an den im Subnet liegenden Bridges?
Ich habe für entferntere AccessPoints Mikrotik SXTs als Bridge eingerichtet. Diese haben (aktuell noch) das Subnet vom Heimnetz.
Ich weiß man sollte dafür andere Subnetze nutzen. Transfernetz usw.
Demnächst stelle ich auf Ubiquiti um, da ich damit besser klar komme als mit den SXTs.
Aber davon ab, kann es daran liegen und wenn ja, wieso?
Wie stellt man das prinzipiell an mit den extra Subnets?
Ich erstelle beispielsweise 10.10.10.X und vergebe da die IPs für die SXTs.
Dann ein Vlan in der pfsense für genau selbiges Subnet und der Freigabe vom Homnet dahinein.
Also Heimnetz, SXT Bridge <-> SXT Bridge, AccessPoint oder Switche welche mit den Subnetzen wieder etwas anfangen können oder wie?
Da ist Vlan 1 für das Heimnetz aber kaum noch möglich oder??
Liegt es vielleicht an den im Subnet liegenden Bridges?
Das wäre möglich ?Hast du denn noich weitere Bridges in diesem Subnet ?? Normal ist sowas ja Steinzeit, weil es keinerlei "Bridges" in dem Sinne mehr gibt !
Ausnahme natürlich sowas wie NIC Bridges im Hypervisor (VMWare, Virtual Box usw.) "Netzwerk Brücken" in der Winblows NIC Einrichtung oder sowas Gruseliges.
Bridges nutzt im Netzwerk heute eigentlich niemand mehr der Performance orientiert ist.
Ich habe für entferntere AccessPoints Mikrotik SXTs als Bridge eingerichtet
Igitt !!Ja das könnte sein, denn du belastest mit einer Bridge dann mit dem gesmaten Broad- und Multicast Traffic beider Netze den Funklink, was dann massiv zu Lasten der Performance geht !
Das wird sicher ein gravierender Grund sein !
Die SXTs sollte man IMMER als Router konfigurieren wenn immer es geht.
"Route where you can, bridge where you must !" ist die goldene Regel des Netzwerkers !
Demnächst stelle ich auf Ubiquiti um, da ich damit besser klar komme als mit den SXTs.
Bringt aber rein gar nix wenn du wieder in ein Bridging Design verfällst !Also Heimnetz, SXT Bridge <-> SXT Bridge
Nein !Wenn du es richtig machst, dann routet einer der SXTs !
Sprich er routet zwischen dem remoten IP Netz und dem lokalen. So eliminiert du eben wenigstens einseitig den Broad- und Multicast Traffic vom Funklink !
Noch besser wäre natürlich die Funkstrecke als eigenes IP Netz zu konfigurieren, damit ist es dann vollkommen von jeglichem Broad- und Multicast Traffic aus beiden lokalen LAN Segmenten an den SXTs isoliert.
Das wäre dann das Optimum !
Da ist Vlan 1 für das Heimnetz aber kaum noch möglich oder??
Nein, wozu denn auch. Du routest ja dann sowieso ! Kein Layer 2 mehr über die Funkbrücke eben wegen der o.a. gravierenden Nachteile in der Performance !
Hmmm.
Also aktuell ist es tatsächlich so, dass ich selbst 192.168.1.x habe, die Switches haben das auch und die SXTs.
Wenn ich jetzt an einem entfernten AP hänge, so bekomme ich die selbe IP, als wäre ich direkt zu Hause.
Ich möchte eigentlich auch keine andere IP haben. Beispielsweise hängt für der eine fritzbox mit an einem entfernten Punkt (die löst das vlan auf, ich weiß) und macht nur Telefon.
Lan wird nicht genutzt.
Würde die dann komplett im anderen Segment sein?
Ich kann mir das alles sehr schlecht vorstellen.
Kann man das zum Verständnis schemenhaft dastellen?
Gestern hatte ich an einer Firewall Regel etwas geändert und gespeichert.
Kurzzeitig hatte ich dann Max Speed und fiel dann wieder ab.
Aber leider ist da nichts blockierendes konfiguriert.
Also aktuell ist es tatsächlich so, dass ich selbst 192.168.1.x habe, die Switches haben das auch und die SXTs.
Wenn ich jetzt an einem entfernten AP hänge, so bekomme ich die selbe IP, als wäre ich direkt zu Hause.
Ich möchte eigentlich auch keine andere IP haben. Beispielsweise hängt für der eine fritzbox mit an einem entfernten Punkt (die löst das vlan auf, ich weiß) und macht nur Telefon.
Lan wird nicht genutzt.
Würde die dann komplett im anderen Segment sein?
Ich kann mir das alles sehr schlecht vorstellen.
Kann man das zum Verständnis schemenhaft dastellen?
Gestern hatte ich an einer Firewall Regel etwas geändert und gespeichert.
Kurzzeitig hatte ich dann Max Speed und fiel dann wieder ab.
Aber leider ist da nichts blockierendes konfiguriert.
so bekomme ich die selbe IP, als wäre ich direkt zu Hause.
Ja, wie vermutet: Ein dummes, flaches Layer 2 Netz und der gesamte Broad- und Multicast Traffic dieses netzes kumuliert af dem Funklink mit seiner begrenzten Bandbreite und belastet diesen.Da kann die Bandbreite dann niemals nur annähernd die von Kupfer erreichen. (Was sie auf dem Funk Link eh niemals kann).
Ich möchte eigentlich auch keine andere IP haben.
Dann wirst du das Problem auch niemals lösen können !! Wasch mich, aber mach mich nicht nass... Ist dir vermutlich selber klar das das dann nix wird ?!Die Segmentierung, sprich das Routing des Funklinks würde andere IP Netze bedeuten...ist ja klar. Du hast ja dann keine doofe Bridge mehr sondern einen Router der IP netze routet.
Grundlagen dazu guckst du hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Kann man das zum Verständnis schemenhaft dastellen?
Ja. Aber besser nicht schemenhaft sondern mit einer guten Skizze...
Ich antworte mal vereinfacht.
Ein Router, ein switch, daran 2 Accesspoints via Kabel.
30 Clients. Aufgeteilt zwischen Kabel und wlan.
Das würde ich in 1 Subnet packen.
Nach meinem Verständnis weiß ein switch ja auch was wo dran hängt.
Und jetzt auf den sxt gemünzt.
2 davon bilden ein NetzwerkKabel zwischen switch und ap 2
Wenn ich jetzt an AP1 hänge, müsste es doch schnell sein.
Ist es aber nicht.
Es ist identisch wie an AP2 über den zusätzlichen Funk Link.
Und das in allen Netzen
Es ist überall gleich schnell oder gleich langsam.
An AP2 verhält sich das alles identisch.
Was jetzt größer gedacht anders ist, ist ein sxt und der versorgt via Multipoint 4 weitere SXTs und daran hängen wie AP2 AccessPoints.
Clients verteilen sich.
Im anderen Subnet ist Internet trotz sxts schneller.
Ein Router, ein switch, daran 2 Accesspoints via Kabel.
30 Clients. Aufgeteilt zwischen Kabel und wlan.
Das würde ich in 1 Subnet packen.
Nach meinem Verständnis weiß ein switch ja auch was wo dran hängt.
Und jetzt auf den sxt gemünzt.
2 davon bilden ein NetzwerkKabel zwischen switch und ap 2
Wenn ich jetzt an AP1 hänge, müsste es doch schnell sein.
Ist es aber nicht.
Es ist identisch wie an AP2 über den zusätzlichen Funk Link.
Und das in allen Netzen
Es ist überall gleich schnell oder gleich langsam.
An AP2 verhält sich das alles identisch.
Was jetzt größer gedacht anders ist, ist ein sxt und der versorgt via Multipoint 4 weitere SXTs und daran hängen wie AP2 AccessPoints.
Clients verteilen sich.
Im anderen Subnet ist Internet trotz sxts schneller.
So sähe das dann aus:
Bessere Version (Eine Seite Routing):
Nachteil: Immer noch Broad- und Multicast Last vom remoten Netz auf dem Funklink !
Ideale Version (Beidseitiges Routing):
Letzteres eliminiert das Grundrauschen beider Netze komplett vom Funklink. Damit überträgt der rein nur noch Nutzdaten auf seiner vollen ihm durch das HF Umfeld diktierten Bandbreite (dynamisch) ganz ohne Belastung vom Resttraffic beider lokaler LANs.
So würde man das Maximum an Performance aus der Infrastruktur rausholen.
Einziger Wermutstropfen bleibt dann nur noch der Funklink selber.
Je nach Nachbarkanalstörung (4 kanaliger Abstand) und Freiraumdämpfung durch Atmosphäre, Wasserdampf und Abhängigkeit der Entfernung hat der ja eine ihm zur Verfügung stehenden Bandbreite. Diese ist aber immer nur ein Bruchteil der Kupfer Bandbreite und ändert sich dynamisch je nach äußerer Situation. Die Bandbreite schwankt hier also immer in bestimmten Größenordnungen die Standort situationsbedingt ist.
Fazit: Sowie Funk im Spiel ist musst du IMMER mit schwankender Performance rechnen !
Bessere Version (Eine Seite Routing):
Nachteil: Immer noch Broad- und Multicast Last vom remoten Netz auf dem Funklink !
Ideale Version (Beidseitiges Routing):
Letzteres eliminiert das Grundrauschen beider Netze komplett vom Funklink. Damit überträgt der rein nur noch Nutzdaten auf seiner vollen ihm durch das HF Umfeld diktierten Bandbreite (dynamisch) ganz ohne Belastung vom Resttraffic beider lokaler LANs.
So würde man das Maximum an Performance aus der Infrastruktur rausholen.
Einziger Wermutstropfen bleibt dann nur noch der Funklink selber.
Je nach Nachbarkanalstörung (4 kanaliger Abstand) und Freiraumdämpfung durch Atmosphäre, Wasserdampf und Abhängigkeit der Entfernung hat der ja eine ihm zur Verfügung stehenden Bandbreite. Diese ist aber immer nur ein Bruchteil der Kupfer Bandbreite und ändert sich dynamisch je nach äußerer Situation. Die Bandbreite schwankt hier also immer in bestimmten Größenordnungen die Standort situationsbedingt ist.
Fazit: Sowie Funk im Spiel ist musst du IMMER mit schwankender Performance rechnen !
Ich werde meines wohl auch mal zeichnen müssen.
Um bei Deinbem letzten Bild zu bleiben.
Alles hat 192.168.1.X
Es gibt zusätzlich auf dem Wlan noch 10.X, 20.X und 30.X
Somit kann ich von der rechten Seite zur linken alles sehen, ist ja wie ein Kabel und der FunkLink reicht massig aus, das ist nicht das Problem.
Nur wieso ist der Client links der direkt daran hängt dann auch langsam, wenn er doch gar nicht die Funkstrecke benutzt??? Mal davon ausgegangen, dass der Client ein AP mit den 4 Subnets ist und das Smartphone im 1er Subnet ist??
Um bei Deinbem letzten Bild zu bleiben.
Alles hat 192.168.1.X
Es gibt zusätzlich auf dem Wlan noch 10.X, 20.X und 30.X
Somit kann ich von der rechten Seite zur linken alles sehen, ist ja wie ein Kabel und der FunkLink reicht massig aus, das ist nicht das Problem.
Nur wieso ist der Client links der direkt daran hängt dann auch langsam, wenn er doch gar nicht die Funkstrecke benutzt??? Mal davon ausgegangen, dass der Client ein AP mit den 4 Subnets ist und das Smartphone im 1er Subnet ist??
So
Ich habe mal etwas getestet und habe den genauen Fehler gefunden.
Ich bin dem Hinweis nachgegangen, dass das Bridging alles lahmlegt.
-Ich habe somit an meinem Hauptswitch die Verbindung in das Nachbarhaus deaktiviert.
Somit war der WLan Test schnell
- Verbindung wieder an, war es langsam.
Somit am Nachbarswitch weiter gemacht, erst dahinter kommen die SXTs (bessere Sichtverbindung)
-SXT Switchport deaktiviert, brachte keine Veränderung.
Somit musste irgendwas auf dem Switch sein.
An dem anderen Switch hängt im 192.168.1.1 Bereich noch ein Speedport. (Ja ich weiß ein Graus und braucht nicht näher erörtert werden)
Da meine pfsense das Internet macht, weil eh schneller läuft alles DHCP technisch zu mir.
Da mein Nachbar aufgrund VoIP aber seine ISDN Anlage weiter benutzen wollte, musste ein Speedport ISDN S0 Adapter her.
Dieser muss über DHCP laufen und hängt an einem der 4 Ports des Speedport. Durch den schmalen Bereich kommen die DHCPs nicht ins gehege.
Ein weiteres Kabel geht vom Router an das Switch.
Dem Switch habe ich auf diesem Link UDP 67+68 geblockt um DHCP Anfragen abzublocken.
Das funktioniert auch soweit mit dem Blocken.
Wie gesagt ich weiß das ist nicht optimal und der gehört eigentlich nicht in die Gleichung.
Aufgefallen ist mir, dass wenn ich den Switchport zu diesem Router deaktiviere ich sofort volldampf habe.
Mir ist das nur schleierhaft, da dort eigentlich nichts hingelangen sollte.
Welcher Port bzw Dienst ist da wohl das Übel?
Nun dachte ich, ich deaktiviere den Port generell.
Nur kommt mein Nachbar dann ja nicht mehr auf den Router für was auch immer. (Der ist auch nicht so firm, eher sein Sohn)
Eigenes VLan wäre vielleicht eine Option.
Den Router in Vlan 80 z.B. stecken und auf dem Switch belassen.
VLAN 80 geht direkt an den Router und direkt an die LAN Ports die noch frei sind.
Zu den Ports die zu mir gehen wird Vlan 80 geblockt und der Port, der weiter geht auch.
Somit müsste er doch noch an den Router kommen, wenn er im Heimnetz ist, aber für mich ist er unsichtbar.
Das wäre aber nur die Notlösung, das mit dem Dienst (Port) wäre mir lieber.
Hier als Bild vereinfacht dargestellt.
Bitte zerreiß mich nicht gleich in der Luft.
Ich weiß der Router sollte da nicht sein, ist er aber leider.
Nun muss ich irgendwie sehen wie ich ihn besser umschiffe.
Gibts da Ideen was da noch herankommen kann?
Ich habe mal etwas getestet und habe den genauen Fehler gefunden.
Ich bin dem Hinweis nachgegangen, dass das Bridging alles lahmlegt.
-Ich habe somit an meinem Hauptswitch die Verbindung in das Nachbarhaus deaktiviert.
Somit war der WLan Test schnell
- Verbindung wieder an, war es langsam.
Somit am Nachbarswitch weiter gemacht, erst dahinter kommen die SXTs (bessere Sichtverbindung)
-SXT Switchport deaktiviert, brachte keine Veränderung.
Somit musste irgendwas auf dem Switch sein.
An dem anderen Switch hängt im 192.168.1.1 Bereich noch ein Speedport. (Ja ich weiß ein Graus und braucht nicht näher erörtert werden)
Da meine pfsense das Internet macht, weil eh schneller läuft alles DHCP technisch zu mir.
Da mein Nachbar aufgrund VoIP aber seine ISDN Anlage weiter benutzen wollte, musste ein Speedport ISDN S0 Adapter her.
Dieser muss über DHCP laufen und hängt an einem der 4 Ports des Speedport. Durch den schmalen Bereich kommen die DHCPs nicht ins gehege.
Ein weiteres Kabel geht vom Router an das Switch.
Dem Switch habe ich auf diesem Link UDP 67+68 geblockt um DHCP Anfragen abzublocken.
Das funktioniert auch soweit mit dem Blocken.
Wie gesagt ich weiß das ist nicht optimal und der gehört eigentlich nicht in die Gleichung.
Aufgefallen ist mir, dass wenn ich den Switchport zu diesem Router deaktiviere ich sofort volldampf habe.
Mir ist das nur schleierhaft, da dort eigentlich nichts hingelangen sollte.
Welcher Port bzw Dienst ist da wohl das Übel?
Nun dachte ich, ich deaktiviere den Port generell.
Nur kommt mein Nachbar dann ja nicht mehr auf den Router für was auch immer. (Der ist auch nicht so firm, eher sein Sohn)
Eigenes VLan wäre vielleicht eine Option.
Den Router in Vlan 80 z.B. stecken und auf dem Switch belassen.
VLAN 80 geht direkt an den Router und direkt an die LAN Ports die noch frei sind.
Zu den Ports die zu mir gehen wird Vlan 80 geblockt und der Port, der weiter geht auch.
Somit müsste er doch noch an den Router kommen, wenn er im Heimnetz ist, aber für mich ist er unsichtbar.
Das wäre aber nur die Notlösung, das mit dem Dienst (Port) wäre mir lieber.
Hier als Bild vereinfacht dargestellt.
Bitte zerreiß mich nicht gleich in der Luft.
Ich weiß der Router sollte da nicht sein, ist er aber leider.
Nun muss ich irgendwie sehen wie ich ihn besser umschiffe.
Gibts da Ideen was da noch herankommen kann?
Alles hat 192.168.1.X
War zu befürchten. Damit hast du das Bridging Problem und die Belastung des Funklinks mit seiner beschränkten Bandbreite. Logisch das du in so einem Konstrukt niemals auch nur annähernd an Kupfer Performance kommen kannnst aufgrund der oben genannten Punkte ! Ist dir aber sicher auch selber klar.Somit musste irgendwas auf dem Switch sein.
Kann das sein das da Flow Control aktiviert ist ?Oder...du hast ein Autonegotiation Problem mit dem Anschlussport. Speed und Duplex Mismatch.
Sowas resultiert immer in lahmende Switches. Oder ein Spanning Tree Problem wenn die Bridge auch Spanning Tree sprechen sollte.
Durch den schmalen Bereich kommen die DHCPs nicht ins gehege.
Das ist Quatsch. Wenn sie gemeinsam in einem Layer 2 Natz sind kommt es zw. den DHCP Servern IMMER zu einer Race Condition, sprich der Schnellere gewinnt. 2 parallele DHCP Server sollte man und darf man nie in einem L2 Segment laufen lassen.Müsstest du ja auch nicht, denn der ISDN Box könntest du in deiner pfSense aufgrund seiner Mac Adresse eine dedizierte IP und Gateway vergeben die anders ist als die des globalen Pools. Damit könnte man den SP DHCP abschalten. Nur mal nebenbei...
an das Switch.
Der Switch ist ein Mann.Dem Switch habe ich auf diesem Link UDP 67+68 geblockt um DHCP Anfragen abzublocken.
OK, damit könnte man dann wieder 2 DHCP betreiben da die sich durch den Filter dann nicht sehen. Das geht...Es bleibt dabei:
Dein Grundproblem ist das BEIDE Netze in einer gemeinsamen Layer 2 Domain liegen und die SXTs bridgen. Also schon im Ansatz ist hier ein falsches IP netzdesign gemacht worden.
Die gesamte Broad- und Multicast Last beider Netze belastet deinen Funklink.
Von Sicherheit mal gar nicht zu reden. In Verbindung mit Funk ist das ein falsches Adress Design.
Das zeigt auch schon das Management Adressen des Switches mitten im Adressbereich liegen. Auch solche kosmetischen Fehler macht man nicht im Adressdesign und legt statische Management IPs immer an den Rand. Oben oder unten und spart diese von DHCP Pools aus.
Hier solltest du also in jedem Falle routen über die SXT Verbindung, das fixt dann vermutlich auch sofort dein Problem. Auch wenns erstmal nur einseitig sein sollte. (Nur ein SXT im Routing Mode)
Die grundsätzliche Frage bleibt warum du das nicht gleich so gemacht hast.
Bridging über Funk ist immer kontraproduktiv !
Ich habe es nach bestem Wissen und Gewissen gemacht.
Die Switche bekommen auch IPs via DHCP, aber nicht aus dem Pool.
Der Pool ist 100-200
Nur ist da oben noch gar kein SXT involviert, das Problem entsteht nur durch den anderen Router, wenn der da ist.
Die SXTs kommen, da leider keine Sternentopologie möglich an der Stelle, hinter dem rechten Switch.
Ich habe dem Speedport, welcher die Probleme macht schon fest auf 100 Mbit gesetzt, auch ohne Erfolg.
Ich Frage mich auch welcher Dienst da wohl noch zwischen spricht.
Das Netz ist auch langsam, wenn ich nur auf dem Hauptswitch bleibe.
Das spricht für mich gegen ein lahmes switch, da es ja außen vor sein sollte oder nicht?
Aktuell ist der Port vom Speedport deaktiviert, aber das soll nicht die Dauerlösung sein.
Oder alles blockieren und nur 80 und 443 durchlassen falls da mal an die Management Webseite aufgerufen werden soll?
Routing habe ich dann auch noch Fragen zu, aber das wird zu viel auf einmal
Die Switche bekommen auch IPs via DHCP, aber nicht aus dem Pool.
Der Pool ist 100-200
Nur ist da oben noch gar kein SXT involviert, das Problem entsteht nur durch den anderen Router, wenn der da ist.
Die SXTs kommen, da leider keine Sternentopologie möglich an der Stelle, hinter dem rechten Switch.
Ich habe dem Speedport, welcher die Probleme macht schon fest auf 100 Mbit gesetzt, auch ohne Erfolg.
Ich Frage mich auch welcher Dienst da wohl noch zwischen spricht.
Das Netz ist auch langsam, wenn ich nur auf dem Hauptswitch bleibe.
Das spricht für mich gegen ein lahmes switch, da es ja außen vor sein sollte oder nicht?
Aktuell ist der Port vom Speedport deaktiviert, aber das soll nicht die Dauerlösung sein.
Oder alles blockieren und nur 80 und 443 durchlassen falls da mal an die Management Webseite aufgerufen werden soll?
Routing habe ich dann auch noch Fragen zu, aber das wird zu viel auf einmal
Ich habe es nach bestem Wissen und Gewissen gemacht.
Aber eben nicht richtig und optimal 
Die Switche bekommen auch IPs via DHCP
Uhhh gruselig. Infrastruktur Komponenten haben immer statische IPs, niemals dynamische. Aber egal...das Problem entsteht nur durch den anderen Router, wenn der da ist.
Dann bläst der irgendwas ins Netz was dein ganzes Konstrukt stört.Wireshark ist hier dein bester freund rauszubekommen WAS das ist !!
Da zeigt sich auch leider die generelle Falschheit deines Designs an sich ! Hättest du segmentiert und geroutet wäre es vollkommen Latte was im anderen Netz passiert und hätte keinerlei Auswirkungen auf Restnetz !!
welcher die Probleme macht schon fest auf 100 Mbit gesetzt, auch ohne Erfolg.
War klar...das ist sinnfrei. Was sollte das auch bringen ??Nimm lieber den Wireshark und sieh dir mal an was der sonst noch so ins Netz bläst !
für mich gegen ein lahmes switch
Gegen einen lahmen Switch ! Der Switch ist ein Mann (maskulin).Oder alles blockieren und nur 80 und 443 durchlassen falls da mal an die Management Webseite aufgerufen werden soll?
Könntest du versuchen. Wäre ein Ansatz.Letztlich kurierst du aber nur die Symptome.
Ursache der Krankheit ist dein falsches Netzwerk Design. Wäre besser langfristig wenn du das anfasst und änderst !
Routing habe ich dann auch noch Fragen zu
Na dann immer her damit ! 
Also wie immer sehr ausführlich, danke dafür.
Der Port ist wieder aktiviert und Wireshark schaut was an 192.168.1.1 passiert.
13653 589.168331 192.168.1.1 224.0.0.1 IGMPv3 60 Membership Query, general
Das jede Minute.
Gibt denke ich schlimmeres.
Ganz früher habe ich mal zusätzlich die 192.168.1.1 als zusätzlichen DNS eingerichtet.
Ich schaue schon überall, finde aber keine Einstellung mehr dazu.
Es dürfte raus sein, aber ich überlege halt was es sein könnte.
Aktuell ist es wieder schneller im Wlan, obwohl der Port aktiviert ist.
Fürchterlich. Ich muss da mal den nächsten Einbruch warten.
Der Port ist wieder aktiviert und Wireshark schaut was an 192.168.1.1 passiert.
13653 589.168331 192.168.1.1 224.0.0.1 IGMPv3 60 Membership Query, general
Das jede Minute.
Gibt denke ich schlimmeres.
Ganz früher habe ich mal zusätzlich die 192.168.1.1 als zusätzlichen DNS eingerichtet.
Ich schaue schon überall, finde aber keine Einstellung mehr dazu.
Es dürfte raus sein, aber ich überlege halt was es sein könnte.
Aktuell ist es wieder schneller im Wlan, obwohl der Port aktiviert ist.
Fürchterlich. Ich muss da mal den nächsten Einbruch warten.
Das jede Minute.
Ist ein IGMP Query (Multicast) !Irgendwo ist bei dir was was etwas ins Netzwerk streamen will Audio oder Video.
Kann aber auch der Switch sein wenn dort IGMP Snooping (richtigerweise) aktiviert wurde.
aber ich überlege halt was es sein könnte.
Dein falsches Design... Es bleibt dabei
Ist das IGMP dramatisch?
Klar gibt's heutzutage FireTV und solch Streaming Geschichten.
Aber hinter dem Speedport sollte eigentlich nichts hängen dergleichen.
Klar gibt's heutzutage FireTV und solch Streaming Geschichten.
Aber hinter dem Speedport sollte eigentlich nichts hängen dergleichen.
Nein ! Wenn du wie gesagt IGMP Snooping aktiviert hast auf deinen Switches ist es normal das dessen IGMP Querier sich zyklisch über die Multicast Adresse 224.0.0.1 meldet.
Kannst du ja im GUI checken !
Die 192.168.1.1 ist aber der Router selber, oder ?
Kann sein das dort Telekom Entertain rennt. IP TV. Das rennt mit Multicast. Ansonsten wäre es sehr ungewöhnlich für einen Speedport.
Kannst du ja im GUI checken !
Die 192.168.1.1 ist aber der Router selber, oder ?
Kann sein das dort Telekom Entertain rennt. IP TV. Das rennt mit Multicast. Ansonsten wäre es sehr ungewöhnlich für einen Speedport.
