Dit is vreemd en ik moet je eerlijk zeggen dat ik dit niet helemaal kan plaatsen. Ik hoop dat iemand in de Community een vergelijkbare opstelling heeft en je tips kan geven.

Dankjewel voor je reactie Remco. Ik snap dat mijn TP-link Omada EAP613 access points specifiek zijn, maar de KPN Box 12 is dat niet en IPv6 ook niet. Daarom heb ik een concrete vraag voor KPN: waarom communiceert de KPN Box 12 een extra IPv6 gateway op de LAN-poorten? Dit lijkt een verkeerde configuratie in de KPN Box. Maar dit is niet iets wat ik zelf heb ingesteld.

Voor andere communityleden: ben ik de enige die twee IPv6 gateways ziet als je ipconfig draait, verbonden met UTP-kabel op de Box 12?

Een bijzonder probleem. De fe80:: adressen moeten van een “router advertisement” komen, en de eerste en hopelijk enige verantwoordelijke daarvoor is de router. De fe80 adressen lijken erg op elkaar, ze worden afgeleid van het MAC adres, dus ze zouden in hetzelfde apparaat kunnen zitten. Een route naar een niet beschikbare interface kan uiteraard problemen geven.

De 2a02….. prefix zit ook in die router advertisement, maar er worden twee prefixen geadverteerd.  wat niet gebruikelijk is

Bij de V10 box is 2a02n:0/64  aanwezig op WAN, 2a02n:1/64 op LAN. Uitgaande  van de V10 configuratie lijkt het alsof een router advertisement voor de WAN op de LAN terecht komt. Contact maken van LAN naar de fe80::/WAN gaat uiteraard niet lukken.

Router advertisement gaan spontaan het net op, of als antwoord op een “router sollicitation”. Ik weet niet of die access points sollicitations uitzenden, in bridge mode mogelijk niet.

Het lijkt dus een box 12 probleem (nieuwe firmware ??? ), de manier om dat aan te tonen is een PC met packet sniffer als Wireshark aan de LAN te koppelen, het source MAC adress in de router advertisement leidt direct naar de boosdoener.

Inderdaad, deze extra router advertisement is zichtbaar in Wireshark als ik filter op “icmpv6.type == 134”.

Iedere circa 34 seconden komt er een normale advertisement voorbij:

• met een /64 reserved “ULA” prefix in fc00::/7
• met een /64 routable prefix in 2a02:a440::/27, dit is de eerste /64 binnen de /48 die de box van KPN ontvangt
• afkomstig van een router ip dat ik kan pingen
• komt zowel solicited als unsolicited
• zowel LAN als WiFi

Iedere circa 250 seconden komt er een merkwaardige advertisement voorbij met 

• met een aanvullende /64 routable prefix, dit is de tweede /64 binnen de /48 die de box van KPN ontvangt
• afkomstig van een router ip dat ik niet kan pingen
• komt uitsluitend unsolicited
• uitsluitend via LAN

De merkwaardige advertisements zijn duidelijk afkomstig van de KPN box 12 (Sagemcom) en niet van het internet. 

Mijn access points sturen geen eigen IPv6 router sollicitations. Ze sturen wel de IPv6 sollicitations door van de clients.

De box heeft firmware versie V12.C.24.05.08. Kan iemand verifieren of de vreemde advertisement bij andere v12 boxen ook zo is?

Bij wie moet ik zijn om dit gedrag er eventueel uit te krijgen?

Alle analyses zijn dus al gedaan! Merkwaardig is dat de advertisements van twee verschillende MAC adressen afkomen, wat klopt met de twee fe80:: adresssen. Het lijkt er dus op dat er wat op een bridge zit dat er niet hoort te zitten. Ik heb box V10 oude firmware, en geen kennis van Box 12. Dus geen idee hoe die intern in elkaar zit. Hebben 2.4/5 GHz verschillende chips? Guest Wifi ook een aparte chip? 

Bij de V10 is IPv6 4e element  :0:: voor WAN en  :1:: voor LAN/Wifi, geen IPv6 op gast. Bij box 12 is blijkbaar element :0:: voor LAN? U zou nog kunnen proberen Wifi onderdelen uit te schakelen.

In ieder geval: Box 12 produceert dubbele RA’s die ipv6-test tot een bedroevende score brengen in is dus fout. Er hoort maar een router te zijn.  Ik weet niet of dit “oude” firmware is of die nieuwe “KPN firmware”, maar in ieder geval is een correctie nodig.

Ik ben ook maar een klant, en Ik denk dat voor dit probleem de  helpdesk bellen zinloos is, maar er lezen mensen mee op dit forum die toegang hebben tot de ontwikkelafdeling. Even afwachten of een van hen zich meldt, in ieder geval: debug informatie staat hierboven!

Geeft de status pagina van de router informatie over de diverse MAC adressen in het systeem?

Ik heb e.e.a. ook eens geprobeerd met dezelfde V12 box thuis. Het gedrag hoe er met deze ipv6 router advertisements omgegaan wordt verschilt nogal per apparaat. Kijkend naar een windows client dan zie ik identiek gedrag van een dubbele ipv6 default gateway verwijzing. Beide zijn afkomstig van de V12 box.

Een macbook zal dezelfde advertisements zien maar lijkt een andere keuze te maken en die gateway te kiezen die overeenkomt met het base mac adres van de V12. Deze informatie is te vinden onder menu instellingen/informatie en dan wat naar beneden scrollen. Hier staan MAC adressen van aanwezige naar buiten gerichte i(wifi)interfaces. Hier zit bv niet de vermelding bij van de interne bridge interface voor gastverkeer.

Het tweede ipv6 default gateway adres is afkomstig vanuit de V12 gerelateerd aan de gast netwerk functie. Dit is te achterhalen door verbinding te maken in het gast netwerk.

Er wordt dus onterecht een extra prefix met gateway adres gepresenteerd die niet bereikbaar is omdat er een scheiding is aangebracht tussen thuisnetwerk verkeer en het gastverkeer.

Overigens merk ik dat dit alleen het geval lijkt te zijn via de lan poorten van de v12 zoals al eerder opgemerkt. Via de wifi van de v12 gebeurt het niet maar als je dus wifi acces points via ethernet hebt aangesloten dan gebeurt die kant op dus ook.

Met deze situatie is het zeker niet ondenkbaar dat er afhankelijk van het type apparatuur en of deze via ethernet is verbonden er  intermitterende communicatieproblemen gaan ontstaan.

Er lijkt niet echt een andere oplossing op korte termijn te zijn dan het uitschakelen van de ipv6 stack totdat dit in de software wordt verholpen. Of die access points via ethernet 4 aansluiten en deze dan omschakelen naar gastnetwerk. Op dat netwerk zie ik geen dubbele gateway voorbijkomen. Maar goed dan is er weer een scheiding richting het thuisnetwerk.

Goedemorgen @paperclip55. Ik wil jou en alle anderen in dit topic als eerste bedanken voor deze uitgebreide en specifieke feedback. Dit is echt waardevol voor ons en dank daarvoor.

Ik heb dit topic en de bijbehorende feedback intern teruggekoppeld want ik moet eerlijk bekennen dat deze materie te specifiek en technisch van aard voor mij is. Maar het is doorgezet. Ik weet niet wat daar op korte termijn achterweg komt maar dit lijkt mij voor nu ook de beste workaround: 

Bruistablet

………

Er lijkt niet echt een andere oplossing op korte termijn te zijn dan het uitschakelen van de ipv6 stack totdat dit in de software wordt verholpen. Of die access points via ethernet 4 aansluiten en deze dan omschakelen naar gastnetwerk. Op dat netwerk zie ik geen dubbele gateway voorbijkomen. Maar goed dan is er weer een scheiding richting het thuisnetwerk.

Nogmaals bedankt voor deze analyses!

Nee, ik heb ook 2 verschillende IPv6 gateways uit 2 verschillende MAC adresses

 

 

De MAC adres van jouw modem zal zijn 84:1e:a3:a6:fb:50, en de 2de is 84:1e:a3:a6:fb:5f, waarschijnlijk afkomstig uit Gastnetwerk voor Poort LAN4

Van mijn apparaten, maar zonder de MAC adres van Gastnetwerk op LAN4 Poort.

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : home
   Default Gateway . . . . . . . . . : fe80::3e58:xxxx:xxxx:98c0%18
                                                fe80::3e58:xxxx:xxxx:98cf%18

Base (Sticker)        3C:58:xx:xx:98:C0
2.4Ghz wifi        3C:58:xx:xx:98:C6
Extra netwerk 2.4Ghz wifi    3C:58:xx:xx:98:C7
Gast netwerk 2.4Ghz wifi    3C:58:xx:xx:98:C9
5Ghz wifi        3C:58:xx:xx:98:CA
Gast netwerk 5Ghz wifi    3C:58:xx:xx:98:CD
Extra netwerk 5Ghz wifi    3C:58:xx:xx:98:CB
 

Ik heb het probleem op een Linux systeem gesimuleerd. Linux laat geen twee default routes toe met dezelfde metric,  maar wel als twee router advertisements binnenkomen. Ze krijgen dan wel een “expires”, maar als de ra’s voldoende vaak herhaald worden, worden die steeds ververst.

Dus:

default via fe80::5054:ff:fe84:ccad dev veth2 proto ra metric 1024 expires 1785sec hoplimit 64 pref medium
default via fe80::5054:ff:fe40:a516 dev veth2 proto ra metric 1024 expires 175sec hoplimit 64 pref medium

ip -6 route get 2a02::1
2a02::1 from :: via fe80::5054:ff:fe84:ccad dev veth2 proto ra src 2001:db8:1:0:dc85:abff:feed:da91 metric 1024 hoplimit 64 pref medium

Het lijkt erop dat de selectie bij Linux simpel is: de bovenste uit de lijst. Als dus bij opstarten van het netwerk een router sollicitatie de goede interface bereikt, komt meteen de advertisement, dus de route boven in de lijst en zal blijven werken.  Zo ook bij MacOSx??

Het source adres is ook een bron van zorg, de gast-prefix zal neem ik aan niet werken via het normale LAN.

De vraag is dus wat Android doet na standby? Ook weer een router sollicitatie of krijgt de “verkeerde” router advertisement de kans de boel te verstoren.

Nog een vraagje: Hoe managed is de PoE+ switch? Waarschijnlijk lukt dat alleen op de duurdere managed switches, maar een ACL op de verbinding met box12 die het gast-MAC adres blokkeert maakt denk ik effectief een einde aan het probleem.

De gast prefix werkt inderdaad niet indien in gebruik door de client omdat er dus een afscherming zit tussen home lan en gast lan.

MacOS zal wel op dezelfde reactielijn zitten als linux. Bij Android telefoons heb je vanuit het gedrag van de smartphone zelf (save/sleep modes) waarschijnlijk veel vaker de kans te eindigen op de black hole route.

Dankjewel voor het doorzetten Remco! Ik hoop dat KPN aan de slag gaat met het oplossen van de bugs.

Bruistablet

Er lijkt niet echt een andere oplossing op korte termijn te zijn dan het uitschakelen van de ipv6 stack totdat dit in de software wordt verholpen. Of die access points via ethernet 4 aansluiten en deze dan omschakelen naar gastnetwerk. Op dat netwerk zie ik geen dubbele gateway voorbijkomen. Maar goed dan is er weer een scheiding richting het thuisnetwerk.

Ik heb de gehele switch met alle apparatuur nu aan ethernet poort 4 gehangen en deze omgeschakeld naar gastnetwerk. Het duurde even voordat dit ging werken, misschien zat er een vertraging in het actief worden van de configuratie. Omdat de access points nu ook aan het gastnetwerk hangen, krijgen ze maar één gateway binnen. Het probleem met wegvallen van IPv6 verbinding is opgelost. Ik heb geen enkele keer meer gemerkt dat een app vastliep. De testperiode was natuurlijk kort maar het lijkt er inderdaad op dat de dubbele router advertisement de oorzaak is.

@TDN Inderdaad, het blijkt dat de dubbele router advertisement afkomstig is van het gastnetwerk. Ik had dit gastwerk niet zelf ingeschakeld en is standaard al actief. Met alle apparaten op het gastnetwerk heb ik toch nog even Wireshark aan een andere lan-poort gehangen. Wat blijkt: niet alleen de router advertisement maar alle multicast en broadcast pakketten van het gastnetwerk worden (zonder 802.1q tag) verzonden op de lan-poorten. Er zit dus iets intern mis met de VLANs in de KPN box en dat is de echt oorzaak van het probleem. Ik vermoed dat VLAN 1977 intern als “untagged” geconfigureerd staat op alle LAN-poorten.

@BruisTablet en @hmmsjan_2 Dankjewel voor de analyses hoe macOS en Linux hiermee om gaan. We kunnen natuurlijk de impact van deze misconfiguratie gaan analyseren voor alle mogelijke besturingssystemen en hardware. Feit blijft dat de KPN box de VLANs niet op orde heeft. Ik stel voor dat KPN het probleem bij de bron aanpakt. Hopelijk kunnen de collega's van @Remco van KPN ons verder helpen op basis van deze VLAN analyse.

In mijn specifieke combinatie van EAP613 access point is het nog iets ingewikkelder: als ik wireshark draai als mijn laptop met zo'n access point verbonden is, dan krijg ik de router advertisements uit het gastnetwerk niet binnen. Deze worden klaarblijkelijk weggefilterd door de access points zelf. Mogelijk heeft deze “feature” iets te maken met de “Legal DHCP Servers” optie in de bijbehorende Omada controller (die ik niet heb). Maar omdat smartphones in een slaapstand gaan, biedt U-APSD hen de optie om deze multicast packets te bufferen om zo energie te besparen. Vermoedelijk werkt het dan net weer anders. Mogelijk laat de access point sommige router advertisements vallen op basis van lifetime van reeds eerder afgeleverde router advertisements. Deze lifetime is langer bij het gastnetwerk. Maar dit zijn allemaal aannames. TP-link access points draaien OpenWRT, maar ze gebruiken ook hardware offloading. Wellicht weten ze alleen bij MediaTek hoe het echt werkt. 

hmmsjan_2

Nog een vraagje: Hoe managed is de PoE+ switch? Waarschijnlijk lukt dat alleen op de duurdere managed switches, maar een ACL op de verbinding met box12 die het gast-MAC adres blokkeert maakt denk ik effectief een einde aan het probleem.

Dit is een TPlink TL-SG108PE. Een simpel ding: de management interface biedt geen opties om MAC-addressen weg te filteren. Het is geen firewall.

Bedankt voor de uitgebreide analyse @paperclip55 voegen we toe aan de feedback. Dank!