Er is ook geen sprake van een ftp sessie bij het downloaden van zo'n configuratiebestand.

Ik ben momenteel druk bezig om een config.boot-bestand op te zetten voor mijn thuisnetwerk i.c.m. een EdgeRouter 12. Ik heb vrijwel alles draaiende, alleen zit ik nog met een paar vragen.

Ik wil graag ook gebruikmaken van IPv6 en dat werkt in de configuratie uit de startpost (ik ga uit van de ER-3 configuratie) prima voor eth1. Ik heb eth1 vervangen door switch0 omdat dat in mijn configuratie het hoofd-LAN is.

Vraag 1:

Waarom is de ipv6 configuratie in het ER-3 script voor eth1 anders dan die voor switch0 in de configuratie voor de ER-X? Welke van de twee is juist, of is die van de ER-X configuratie ook voldoende om een IPv6 adres te verkrijgen? De dhcpv6-pd configuratie is (op de eth1/switch0 interface naam na) wel hetzelfde voor zowel de ER-3 als de ER-X.

ER-3:

ethernet eth1 {
 address 192.168.2.254/24
 description Thuis
 duplex auto
 ipv6 {
 dup-addr-detect-transmits 1
 router-advert {
 cur-hop-limit 64
 link-mtu 0
 managed-flag false
 max-interval 600
 name-server 2a02:a47f:e000::53
 name-server 2a02:a47f:e000::54
 other-config-flag false
 prefix ::/64 {
 autonomous-flag true
 on-link-flag true
 valid-lifetime 2592000
 }
 radvd-options "RDNSS 2a02:a47f:e000::53 2a02:a47f:e000::54 {};"
 reachable-time 0
 retrans-timer 0
 send-advert true
 }
 }
 speed auto
}

ER-X:

switch switch0 {
 address 192.168.2.254/24
 description "Thuis netwerk"
 ipv6 {
 dup-addr-detect-transmits 1
 }
 mtu 1500
 switch-port {
 interface eth2 {
 }
 interface eth3 {
 }
 interface eth4 {
 }
 vlan-aware disable
 }
}

Vraag 2:

Mijn hoofd-LAN (VID1) loopt op switch0. Ik heb daarnaast ook nog een VLAN draaien voor gasten. Dat zit op switch0.40 (VID40). Ik wil graag aan de apparaten op dat VLAN ook IPv6 adressen geven. Hoe doe ik dat?

Ik vermoed dat de dhcpv6-pd configuratie er dan als volgt uit moet zien. Is dit juist?

dhcpv6-pd {
 no-dns
    pd 0 {
    interface switch0 {
        host-address ::1
            no-dns
            prefix-id :1
            service slaac
        }
 interface switch0.40 {
        host-address ::1
            no-dns
            prefix-id :40
            service slaac
        }
        prefix-length /48
    }
    rapid-commit enable
}

Ik vermoed dat ik de ipv6 configuratie van het VLAN (vif 40 onder switch0) dan hetzelfde moet instellen als die van de hoofd-LAN (eth1 in de ER-3 configuratie / switch0 in de ER-X configuratie - zie hierboven)?

Vraag 3:

Ik heb momenteel ook al een boel IPv4 firewall rules staan die ervoor zorgen dat apparaten uit het gast-VLAN niet bij het hoofd-LAN kunnen. Maar hoe zit dat als de apparaten een IPv6 adres krijgen? Moet ik dan IPv6 firewall rules aanmaken (hoe?) of kunnen de apparaten überhaupt niet onderling met elkaar ‘praten’? Als ik wel firewall rules aan moet maken; hoe doe ik dat dan?

@wjb  nogmaals heel erg dank voor alle hulp. Volgens mij ben ik er bijna. :)

Het ipv6 gedeelte van eth1 zou je 1 op 1 moeten kunnen kopiëren naar switch0 en naar de vlan(s) waarvoor je ipv6 actief wilt hebben.

In het dhcpv6-pd gedeelte mag je de no-dns entries verwijderen.

Voor het blokkeren van al het inkomende IPv6 verkeer vanaf het gasten netwerk kan je een kopie van de v6 rules voor de WAN poort kunnen gebruiken.

Thanks.

De ipv6 cnfiguratie zoals die in de ER-X configuratie staat is dus niet juist?

Klopt.

Nou, het is gelukt!

Mijn gehele netwerk draait nu via de EdgeRouter 12, inclusief iTV en VoIP (Experia Box als ATA). :)

Enorme dank aan @wjb voor de configuratiebestanden die ik als basis heb kunnen gebruiken!

Ik heb na de ER-12 overigens nog een EdgeSwitch 8 150W hangen. Alles na die switch kreeg geen IPv6 adres.

Oorzaak: MLD snooping staat standaard uit. Na het inschakelen van MLD Snooping via SSH werkt alles vlekkeloos:

enable
config
set mld
exit
write memory
exit
exit

Fijne jaarwisseling en een goed 2020! 

IPv6 SLAAC maakt veel gebruik van multicasts en op veel switches waarop IGMP snooping aangezet wordt komen dergelijke multicasts vaak niet meer op hun eindbestemming.

Op Netgear switches moet de optie "Block Unknown Multicast Address" daarom ook op disabled staan.

Zie ook dit topic.

Klopt inderdaad. Op de GS105Ev2 waar ik de TV-ontvangers aan heb hangen, stond IGMP snooping standaard aan en die Block Unknown Multicast Address optie stond ook standaard uit. Dat is dus prima.

Op de EdgeSwitch staat IGMP snooping standaard uit (ik heb het aangezet). MLD snooping moet je dan dus ook nog handmatig inschakelen als je IPv6 verkeer goed wilt laten lopen. :)

Nog een vraagje:

Ik heb in mijn hoofd-LAN (VID1) een Intel NUC die o.a. Pi-hole draait. De NUC krijgt netjes een IPv6 adres, maar ik zou er graag zeker van willen zijn dat deze (in ieder geval in het interne netwerk) altijd hetzelfde IPv6 adres heeft.

Dan kan ik die namelijk als DNS server meesturen richting de clients. Ik heb reeds een IPv4 static mapping voor de NUC, maar is zoiets ook mogelijk voor IPv6?

Een apparaat heeft drie IPv6 adressen.

Het local link IPv6 adres beginnend met fe80: Dit IPv6 adres zal altijd hetzelfde zijn.

Het vaste IPv6 adres beginnend met iets als 2a02:a442: Dit iPv6 zal ook altijd hetzelfde zijn.

Daarnaast is er een derde dynamisch IPv6 adres beginnend met iets als 2a02:a442: dat elke paar minuten wijzigt. Dit adres is om te browsen op Internet zonder daarbij het eigen (vaste) IPv6 adres prijs te geven.

Je kunt de vaste IPv6 adressen herkennen doordat daar het MAC adres van het apparaat in verwerkt is.

Aha, duidelijk. Ik ga het eens bekijken.

Bedankt weer!

Hmm, ik heb gekeken maar zie geen IPv6 adressen waar ook maar iets van het MAC adressen in terug te vinden is.

Als ik ifconfig draai (de NUC draait Ubuntu 18.04.3 LTS) zie ik onder de eno1 interface een zestal inet6 regels (waarvan eentje het link-local adres)… het eerste adres dat met 2a02 begint kan ik pingen (ping6) vanaf een ander apparaat, maar hoe weet ik of dat adres statisch is?

Is er een "echt" IPv6 adres dat eindigt op dezelfde reeks als het link local IPv6 adres?

Dat zal namenlijk dan het vaste IPv6 adres.

Er kunnen inderdaad meerdere dynamische IPv6 adressen actief zijn omdat deze actief blijven zolang deze nog gebruikt worden in de communicatie met een server. Alleen de nieuwste wordt gebruikt voor nieuwe communicatie.

Nee, geen van de overige adressen eindigt op hetzelfde als het link-local adres.

Ik heb overigens even zitten Googlen en kom iets tegen over zgn. privacy extensions/privacy addresses. Ik vermoed dat dat het is, want ik kwam ook iets tegen over een Synology NAS die dat niet zou gebruiken. Laat ik ook een Synology NAS in het hoofd-LAN hebben zitten en inderdaad, daar is wel het MAC adres in het IPv6 adres te herkennen.

Probleem met die privacy addresses (ofja, eigenlijk is het heel het doel van die RFC standaard) is dat het dus geen vast adres meer is, maar eentje die om de zoveel tijd verandert:

https://www.internetsociety.org/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/

Nu kan ik dit misschien uitschakelen op de NUC, maar ik weet niet of dat de verstandigste keuze is?

Precies, daarom ook meerdere IPv6 adressen, één vaste gebaseerd op het MAC adres en de dynamische (privacy) adressen die telkens wijzigen zodat het vaste IPv6 adres niet prijsgegeven hoeft te worden (anti tracking/surveillance).

Je moet er absoluut voor zorgen dat je met het dynamische IPv6 adres op Internet actief bent en nooit met het vaste IPv6 adres. Puur omwille van jouw privacy.

Snap ik, maar welk adres kan ik dan wel gebruiken om te verwijzen naar de NUC? Zoals ik zie staat er geen IP adres met herkenbaar MAC in het lijstje bij ifconfig.

Ik denk dat ik het link-local router IPv6 (dat bevat het MAC adres) als name-server mee ga geven en daar DNS forwarding instel. Ik gebruik niet de KPN DNS servers (voor het gasten VLAN geef ik de IPv4 en IPv6 Google DNS servers aan clients).

Ik weet niet wat je moet instellen op ubuntu voor IPv6 SLAAC dus daar ben je op jezelf aangewezen. 

Okay, toch bedankt. ;-)

Link-local als DNS werkt ook niet helaas; zojuist geprobeerd. Dan is dat iets om volgend jaar uit te zoeken. :P 

Ik heb ook een EdgeRouter 12 en heb mijn configuratie overgezet van mijn EdgeRouter X SFP. Nu heb ik heel af en toe dat het beeld even bevriest. Lijkt erger te worden op sommige discovery kanalen uit het pluspakket.

Ik ben benieuwd of jij JorisV hier ook last van hebt met de ER-12 en zou je config graag willen vergelijken met die van mij.

Allereerst: staat de route richting het IPTV platform als type kernel in het lijstje? Zo nee, kopieer dan nog het classless routes script naar de /config/user-data map en kopieer het copy-script naar de /config/scripts/post-config.d map.Zet ook eens de TV-ontvanger(s) uit, herstart de EdgeRouter en start vervolgens eens de TV-ontvanger op.

Heb je de TV-ontvanger rechtstreeks op de ER-12 aangesloten? En zo ja, heb je deze aangesloten op een poort die binnen de switch0 interface valt? Alle EdgeRouter modellen ondersteunen op de switch interface géén IGMP snooping (maar dus wel de IGMP proxy). Daardoor komt het multicast verkeer dat over de switch0 interface loopt overal terecht en dat kan voor haperingen zorgen.

Wat ik heb gedaan is een apart IPv4 subnet met eigen DHCP server gemaakt voor de KPN apparaten (ik heb dat KPN-LAN genoemd, 192.168.100.0/24). Deze heb ik op eth8 gezet (die valt sowieso buiten de switch, maar als je een switch poort gebruikt moet je deze uit de switch0 interface halen). Op die poort heb ik een GS105Ev2 switch aangesloten waarop IGMP snooping ingeschakeld is. Daarop vervolgens de twee TV-ontvangers aangesloten. Als je maar één TV-ontvanger hebt, kun je ‘m rechtstreeks op de ER-12 aansluiten.

Zowel de switch als de twee TV-ontvangers heb ik een static mapping voor aangemaakt (binnen het 192.168.100.0/24 subnet dus). Vervolgens een Firewall/NAT group van type address-group aangemaakt genaamd KPN-IPTV en daar de twee IP adressen van de TV-ontvangers in gezet. Maak ook nog een tweede address-group aan en zet daar het subnet in: 192.168.100.0/24. Ik heb die KPN-LAN genoemd. Bij de NAT rules gebruik je die KPN-IPTV address-group om aan te geven dat het verkeer van alleen de TV-ontvangers richting het IPTV platform moeten gaan (dus niet de switch). Bij de IGMP proxy stel je vervolgens eth8 als downstream in.

Met bovenstaande configuratie verlies je overigens wel de mogelijkheid om te casten naar de TV-ontvangers, maar dat gebruik ik zelf niet. Ik heb trouwens ook nog wat firewall rules toegevoegd om ervoor te zorgen dat de TV-ontvangers geen contact kunnen zoeken met het hoofd-LAN (als je dat ook wilt: let even op want je moet wel IGMP verkeer  toestaan, anders kunnen de TV-ontvangers zich niet afmelden van de streams en loopt je netwerk vol. Been there, dome that. :P).

Hopelijk kom je hiermee verder.

Bedankt voor je snelle reactie.
De IP-TV apparaten in een eigen IPv4 subnet (KPN-LAN) lijkt dan ook de enige oplossing.
Ik heb nog wel een GS108Ev3 die ik kan aansluiten op eth8. Maar ik heb 4 ontvangers waarvan de netwerkkabels van 2 in de ER-12 en 2 boven in een ES-10XP zitten.
Misschien is een KPN-VLAN wel de oplossing. We gaan verder puzzelen.  

Zojuist mijn EdgeRouter X binnen gekregen en de configuratie zonder telefoon ingeladen. Alles lijkt te werken (ben eindelijk de haperingen op de TV boven kwijt), maar op een of andere manier werkt Netfilx niet meer en het internet ook niet. Heb alles thuis voor het 192.168.2.* netwerk geconfigureerd en zou dus moeten werken.

Kan het zijn dat er iets noet goed staat ingesteld in de config file?

Ik zou dan eigenlijk geen probleem verwachten.

Zie je in de dashboard jouw publieke IP adres bij de pppoe0 poort?

Ik heb zojuist geprobeerd om een VLAN op de switch0 interface te maken, omdat ik dan de 2 overgebleven poorten van de switch nog voor andere doeleinden kan gebruiken (twee van de poorten untagged op het KPN-VLAN) en eventueel op de switch boven ook nog TV ontvangers zou kunnen aansluiten.

Dat werkt in principe prima, maar ik zie helaas dat het ontbreken van IGMP snooping op de EdgeRouter weer roet in het eten gooit. :-(

Het multicast verkeer van de TV-ontvangers loopt dan ook op alle andere poorten van de switch0 interface. dat is dus helaas geen goede oplossing. Ik heb het weer teruggedraaid.

En… ik bedenk dat inschakelen van VLAN aware  op de switch0 interface (en juist instellen van de PVID en VID waardes) zomaar eens de oplossing daarvoor kan zijn. Stom dat ik vergeten ben dat te proberen! Moet morgen helaas weer aan de bak maar ga het komend weekend denk ik nog eens proberen.