Effectivement, ton besoin est très très précis. Tu as regardé côté Meraki ? Un des modes de fonctionnement permettant le L3 Roaming pourrait satisfaire une partie de ton besoin: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Layer_3_Roaming
On 7 mai 2018 10:56 +0200, Jérôme Nicolle <jer...@ceriz.fr>, wrote: > Salut David, > > Le 04/05/2018 à 17:13, David Ponzone a écrit : > > Remonter le taffic en L2 depuis les AP, c’est un peu le mode standard de > > fonctionnement d’un AP non (en bridge quoi) ? > > Tout à fait, dans le cas d'un simple LAN en tout cas. > > Sur un site un peu étendu et avec un contrôleur qui centralise les flux, > tu vas remonter tout le trafic L2 vers le contrôleur par quelque méthode > d'encapsulation disponible, pas toujours transparente à IPv6. > > Mon problème est un poil plus complexe : j'ai plusieurs milliers de > sites avec plusieurs dizaines (voir plus) d'AP par site, et rien de plus > que des routeurs sur chaque site. Le trafic WiFi passe par un L3VPN (qui > voudrait d'un VPLS à cette échelle…), les contrôleurs d'accès et nœuds > CGNAT sont dans le backbone. > > > Il faut que les terminaux puissent voir en L2 l’équipement qui va faire > > le DHCPv6, donc le portail-captif à priori. > > Dans le setup actuel, en IPv4 uniquement donc, les routeurs font DHCP > local sur un range dédié à chaque site, et on les bascule bientôt vers > du DHCP relay (en même temps que le déploiement de DHCPv6 relay du coup) > pour pouvoir corréler les baux v4 et v6 plus simplement. > > > Et les terminaux qui ne font pas de DHCPv6, ils peuvent pas faire un > > fallback sur SLAAC ? > > C'est un des problèmes que je cherche à adresser, à priori en remontant > périodiquement ou sur trap l'état de la table NDP du routeur local. Il > faut que ce soit très réactif pour avoir le temps de pousser les règles > de PBR aux bons endroits avant qu'une tentative de connexion ne bypasse > le captive portal. > > L'autre problème c'est qu'on a un quota de bande passante normalement > par login, mais en pratique plutôt par device (demux sur l'IPv4), et > qu'il faut que j'arrive à partager les ressources par device peu importe > le protocole IP, c'est à dire d'avoir des queues de QoS communes entre > IPv4 et IPv6 (et du coup un demux par addresse MAC, qui n'est pas > visible au niveau du backbone puisque les flux passent par un L3VPN). > > Pour l'instant je n'ai trouvé aucun équipementier qui ne propose ne > serait-ce qu'une piste. > > Des idées ? > > Bon, au niveau purement WiFi j'ai bien-sur d'autres problèmes, comme la > façon de gérer le first-hop security et le multicast, et là si vous avez > des suggestions d'AP qui offrent assez de souplesse pour ça, je suis > aussi preneur. > > Merci ! > > -- > Jérôme Nicolle > 06 19 31 27 14 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
