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?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 392424
Url: https://administrator.de/forum/pfsense-hauptsubnet-langsam-und-vlan-sehr-schnell-392424.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
26 Kommentare
Neuester Kommentar
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.
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
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.
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 !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...
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 !
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.
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 !
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.