@wjb : deze taal versta jij 
Wat is de pvid van de LAN poort waar de NTU op aangesloten is?
Staat vlan 6 tagged of untagged op die poort?
Wat is de pvid van de LAN poort waar de Pi 4B op aangesloten is?
Staat vlan 6 tagged of untagged op die poort?
Wat is de pvid van de LAN poort waar de NTU op aangesloten is? -- is switch port, trunk mode. PVID 1
Staat vlan 6 tagged of untagged op die poort? -- tagged
Wat is de pvid van de LAN poort waar de Pi 4B op aangesloten is? -- 1, is trunk port
Staat vlan 6 tagged of untagged op die poort? -- Tagged
De vlan instellingen staan goed anders zou ik helemaal geen verbinding hebben. Ik heb ook alles (meer dan) twee maal gecontroleerd.
Ik zou wel een untagged poort aan kunnen maken en dan via een tweede adapter zonder vlan proberen, kijken of dat iets uitmaakt.
Klopt het dat jouw LAN ook via dezelfde poort van de Pi 4B weer teruggeleid wordt naar die switch?
Op welk vlan gebeurt dat?
ik heb meerdere vlans, 0.a. 2 voor wifi en een voor lan. Voor elk van deze netwerken heb ik een virtuele adapter aangemaakt, bijv lan = eth0.1971 en wifi is eth0.1969. in totaal gebruik ik 6 vlans die allen tagged de Rpi in/uit gaan. Een echte trunk port dus.
Voor de wan heb ik een eth0.6 aangemaakt en als protocol PPPoE. In de firewall staat masquerading aan (NAT)
Eth0 (native) heeft geen protocol en wordt feitelijk niet gebruikt.
Als er op de switch maar niets op vlan 1 staat of (beter) vlan 1 weggehouden wordt van de poort richting NTU dan is het goed.
De switch forceert PVID 1 untagged op die poort omdat er minimaal 1 tagged vlan over die poort gaat (in dit geval 6).
De switch forceert PVID 1 untagged op die poort omdat er minimaal 1 tagged vlan over die poort gaat (in dit geval 6).
Je kunt natuurlijk ook de PVID van de poort naar de NTU op 6 zetten en vlan 6 tagged houden.
Waarom staat vlan 6 tagged op 4 poorten?
Standaard doe ik alle vlans op een trunk zetten, meer niet. Ik zou ze bij 2 er uit kunnen halen. Is iets makkelijker als ik de poort configs moet wijzigen. Ik heb 2 switches, een 8 poort in de meterkast en een 24 poort Cisco SG200 boven op zolder, uiteraard verbonden via een trunk. Ik wil alle vlans boven ook beschikbaar hebben, vandaar (techneut he)
Als ik de PVID op 6 zet dan vertaalt hij vanuit de NTU alle untagged pakketten de switch in ook naar vlan 6….
En dat heb ik trouwens ook geprobeerd, geen succes. (wat ik ook verwachtte, maar ben bereid alles te proberen nu)
Ik begin te vermoeden dat de dell switch misschien een probleem heeft, het is een oud ding en ondersteunt ook geen stp.
Ik heb nog een usb3 Gbit adapter die werkt op de Rpi, ik zal daar eens de NTU direct aanhangen (met vlan 6 uiteraard) zonder de switch ertussen.
Wordt vervolgd.
Als ik de PVID op 6 zet dan vertaalt hij vanuit de NTU alle untagged pakketten de switch in ook naar vlan 6….
Alleen op de poort naar de NTU zet je de PVID op 6 zodat je in ieder geval alle andere vlans weghoudt van de NTU.
Persoonlijk zou ik vlan 6 ook alleen op de poorten richting NTU en richting Pi 4B plaatsen en op geen enkele ander poort vlan 6 aanbieden.
Zelf heb ik gebruik ik 5 vlans op mijn netwerk en die distribueer ik alleen naar de locaties waar die echt gebruikt worden.
Overigens gebruik ik een EdgeRouter 4.
Ja, Ubiquiti ben ik ook erg van gecharmeerd, ik heb vandaag die waardeloze KPN super wifi punten teruggebracht naar de kpn winkel. Mooi 200 terug wat ik kan gebruiken om een mooie nieuwe unifi 6 AP te bestellen wanneer die beschikbaar komt :)
Ik snap je insteek met alleen distribueren naar waar het gebruikt wordt. Is een best practise. Ongebruikte vlans zorgen ook voor packets op de trunk, maar ik stel niet zo heel veel eisen en gigabit still makes me happy!
Ik ga zowiezo via een aparte ethernet adapter een verbinding opzetten naar de NTU, dan weet ik zeker of het de switch is of niet. en als dat faalt zal ik ook de vlans op de trunks uitdunnen. Zoals ik zei, ben bereid alles te proberen 
ik zal ook eens in de diagnostiek van de switch kijken naar eventuele packetloss...
Ik laat het weten.
Ik ben er nog niet van overtuigd dat de problematiek in de switch zit, ook de Raspberry Pi 4B kan uiteraard de oorzaak huisvesten.
Natuurlijk kan dat echter mijn ervaring met vlans in OWRT/Rpi is uitstekend, nooit problemen mee gehad, dus niet mijn eerste verdachte.
Natuurlijk kan dat echter mijn ervaring met vlans in OWRT/Rpi is uitstekend, nooit problemen mee gehad, dus niet mijn eerste verdachte.
Ik heb ook niet het idee dat de oorzaak in die vlans gezocht moet worden.
De enige reden waarom ik over vlans begon was vanwege het weghouden van communicatie op het lan bij de NTU. Dat is ook waarom ik voor de poort richting NTU zou kiezen voor pvid 6 met vlan 6 tagged zodat je zeker weet dat alle andere communicatie de NTU niet kan bereiken.
Ik snap je insteek met alleen distribueren naar waar het gebruikt wordt. Is een best practise. Ongebruikte vlans zorgen ook voor packets op de trunk, maar ik stel niet zo heel veel eisen en gigabit still makes me happy!
Ik ga zowiezo via een aparte ethernet adapter een verbinding opzetten naar de NTU, dan weet ik zeker of het de switch is of niet. en als dat faalt zal ik ook de vlans op de trunks uitdunnen. Zoals ik zei, ben bereid alles te proberen ik zal ook eens in de diagnostiek van de switch kijken naar eventuele packetloss...
Ik laat het weten.
Ik zou even goed de verschillen met Glasnet onder de loupe nemen. Als bij dat kabelmodem internet op untagged zat, heb je makkelijk maar 1 kanaal.
Zo aan je config te zien heb je een pad tussen je LAN en de NTU, naast het pad van de router/pppoe. Dat Untagged 1 van de poort6 weghalen volgens mij. Er zijn switches waarbij dat niet kan, zie diverse (oude) berichten op internet wat dat voor problemen kan opleveren als je daarin de ethernetkabel plugt.
@tmoesel
Glasnet had gewoon een normale ethernet verbinding zonder 803.2q (vlan tagging).
De screenschots van de dell switch die je ziet geven niet de complete configuratie weer. In deze switch zijn geen LAN poorten geconfigureerd (Die zijn toegewezen in de 24 poorts switch). LAN poorten verzenden VLAN (1971) als untagged frames en hebben 1971 als PVID, vlan 1 wordt hierdoor geblokkeerd. Sterker nog ik heb ze als Access poort geconfigureerd. Het is alleen zo dat wanneer je een non-vlan aware ethernet adapter aan een trunk poort koppelt, dat je dan aan de native vlan gekoppeld wordt(1). Handig voor management.
Maar wat je voorstelt ga ik zowiezo proberen, ik laat niets aan toeval over.
Het is alleen zo dat wanneer je een non-vlan aware ethernet adapter aan een trunk poort koppelt, dat je dan aan de native vlan gekoppeld wordt(1).
Die wordt dan aan de vlan gekoppeld die als pvid op de betreffende trunk poort is gedefinieerd. Dat hoeft dus niet het native vlan te zijn.
Klopt, maar in dit geval is dat wel zo. De switch webinterface zelf zit ook op 1. Ik kan hem alleen benaderen als ik een aparte ethernet adapter op de trunk port aansluit. Vanaf lan of ander vlan kan ik de switch niet benaderen. Dat lijkt me toch wel aangeven dat vlan1 niet wordt doorgegeven aan de verkeerde poorten. (Naast het feit dat het twee verschillende subnets zijn die elkaar technisch gezien helemaal niet kunnen zien)
Ik ga iig die wan poort van PVID 1 afhalen, uiteraard zal ik laten weten wat de uitkomst is. Eerst via aparte ethernet adapter zonder switch ertussen om te kijken of het op die manier wel werkt of niet.
Heren, even in navolging van mijn problemen:
Ik heb alle adviezen hierboven uitgevoerd, echter de problemen blijven. Heel specifiek, nslookup en ping van websites werkt 100% OK, maar een website laden gaat bij specifieke sites langzaam of is helemaal onbereikbaar. Bijv. kpn.com is totaal onbereikbaar, tweakers.net is traag, maar bijv. youtube is bliksemsnel , en bittorrent werkt ook prima. Verdenkingen zijn nu verschoven naar een layer 2 issue, de ethernet frames dus, ik heb de kpn techdesk hier ook over gesproken. Dit probleem steeg deze meneer ook snel boven het hoofd, en hij heeft het in de grote groep gegooid zodat eventuele linux experts zich hierover kunnen bogen.
Zodra ik de kpn modem er weer tussen hang, werkt alles weer 100%. Het probleem ligt waarschijnlijk niet in de KPN zijde. Wellicht dat de MTU er mee te maken heeft, alhoewel ik daar ook mee ge-experimenteerd heb. De problemen bleven onveranderd of de verbinding wilde niet eens tot stand komen.
Ik zal een update plaatsen zodra ik verder gekomen ben hiermee met de techdesk. Aan allen die getracht hebben te helpen, mijn vriendelijke dank in ieder geval :)
Heren, mocht u dit nog volgen heb ik de volgende informatie:
Ik heb helaas niets meer van de KPN tech desk gehoord (sta er ook niet van te kijken, ik kreeg het idee dat mijn probleem en jargon hun al snel over het hoofd vloog). Ik heb mijn eigen netwerk nog flink onder de loep genomen, en ontdekt dat mijn Dell switch altijd PVID 1 untagged op een trunk forceert, ook al staat deze ingesteld om hem niet door te laten (ik ben al op zoek naar een vervangende switch). Dit heb ik op kunnen lossen door de PVID op 4095 te zetten (Virtual guest tagging), in dit geval houdt het in dat alle untagged verkeer geblokkeerd wordt. Helaas bracht het geen oplossing voor het initiele probleem, de verbinding blijft hapeneren met exact dezelfde symptomen. Dit verbaasde mij niet echt aangezien mijn poging verbinding te maken met een geheel aparte netwerkadapter die uitsluitend tags met ID 6 doorlaat, ook faalde, ook met exact dezelfde symptomen.
Als volgende ga ik een hardware router configureren voor de pppoe verbinding, ik zal de resultaten hiervan ook posten.
Mocht iemand nog een suggestie hebben dan hoor ik die heel graag. Bij voorbaat dank!
De nieuwste versie van OpenWrt op een RPi 3B+ gaat als een trein, direct op de WAN NTU. Geen gehannes met de verbinding, gelijk werken en gaan, geen problemen met onbereikbare sites. Alleen de RPi 3B+ Haalt niet hoger dan ~ 120 Mbps vanwege de USB2 bottleneck. Dus dat is uitsluitend een test optie.
Volgende stap: Bug fix request indienen bij de devs van OWrt…
Ik sluit dit topic. Iedereen die meedacht, mijn vriendelijke dank.
