La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: kgersen le 24 septembre 2015 à 19:14:29
-
Je viens de commander un des nouveaux serveurs VPS d'OVH de la gamme SSD: https://www.ovh.com/fr/vps/vps-ssd.xml
A ma grande surprise et contrairement a la version 2014 qui était moins cher, cette gamme pourtant tout récente n'a pas d'IPv6 ! meme pas en option...
Quelle déception et quelle régression ... c'est juste incompréhensible.
-
À ce propos, où on est-on en matière de concurrence sur l'hébergement dédié ou VPS à l'échelle mondiale (pour les premiers prix) ?
Sur les dédiés, la France (Kimsufi/Dédibox) est-elle toujours imbattable en matière de tarifs ?
Sur les VPS, qu'en est-il ? Je crois que le marché a évolué, par exemple Digital Ocean (https://www.digitalocean.com/) propose des VPS à prix comparable avec plus d'espace SSD mais moins de RAM et une limite de trafic (2 To).
Si j'ai bien compris, ce que proposent Google ou Microsoft n'est pas à classer dans la même panier car on s'adresse souvent à des structures plus grosses, avec des tarifications à la ressource consommée et/ou de manière moins globale qu'un vrai système complet ?
-
À ce propos, où on est-on en matière de concurrence sur l'hébergement dédié ou VPS à l'échelle mondiale (pour les premiers prix) ?
Sur les dédiés, la France (Kimsufi/Dédibox) est-elle toujours imbattable en matière de tarifs ?
Sur les VPS, qu'en est-il ? Je crois que le marché a évolué, par exemple Digital Ocean (https://www.digitalocean.com/) propose des VPS à prix comparable avec plus d'espace SSD mais moins de RAM et une limite de trafic (2 To).
Si j'ai bien compris, ce que proposent Google ou Microsoft n'est pas à classer dans la même panier car on s'adresse souvent à des structures plus grosses, avec des tarifications à la ressource consommée et/ou de manière moins globale qu'un vrai système complet ?
Je n'ai pas vraiment comparé les prix car effectivement aux US le trafic est souvent limité.
L'avantage du nouveau VPS SSD d'OVH est que contrairement a l'ancien il est compatible Docker (containers) et ce pour moins de 5€/mois. Pour du tests ou du dev c'est idéal.
J'attend toujours une offre 'pure Docker' ou on 'loue' le fait de faire tourner des containers. Pour l'instant c'est 'timide', https://giantswarm.io et https://www.tutum.co/ sont emblématiques de ca mais toujours en beta. Online et OVH avancent plus que timidement la dessus.
Mais meme un Google peut intéresser un particulier ou une TPE avec son offre Cloud facturée a la demande (pour Docker leur offre est gratuite jusqu'a 5 noeuds (https://cloud.google.com/container-engine/) mais il faut payer les VM qu'il y a derrière ca).
-
Ce n'est pas un cas isolé.
-
J'attend toujours une offre 'pure Docker' ou on 'loue' le fait de faire tourner des containers. Pour l'instant c'est 'timide', https://giantswarm.io et https://www.tutum.co/ sont emblématiques de ca mais toujours en beta. Online et OVH avancent plus que timidement la dessus.
Bonjour,
Concernant l'offre Docker, OVH a annoncé hier lors de son summit sa volonté de mettre en production l'offre actuellement en beta sur RunAbove : http://labs.runabove.com/docker/. A suivre mais je suis aussi très demandeur.
-
oui a suivre et en espérant qu'il y a aura IPv6 la dessus.
-
j'ai testé aussi l'offre similaire chez Online: https://www.scaleway.com/
meme combat: pas d'IPv6...
-
j'ai testé aussi l'offre similaire chez Online: https://www.scaleway.com/
meme combat: pas d'IPv6...
ils bossent dessus ;)
Mik
-
On ouvre les paris, qui y arrivera en premier ? OVH ou Online.net ?
-
Le pire c'est la manière dont ils l'emplèmentent chez online.net et ovh, avec du dhcp... Et on ne peut pas s'en passer parce que si on envoie pas de requête et bien ça route pas.
-
Le C1 a plus de stockage ( pas négligeable ) que VPS SSD1 mais que vaut le CPU ARM par rapport au 1vCore ?
Y'a aucune différence en terme de configuration si je veux héberger un site ou faire un vpn ?
:)
-
cali: quelle est la bonne manière ?
IP et routage statique ?
-
Le C1 a plus de stockage ( pas négligeable ) que VPS SSD1 mais que vaut le CPU ARM par rapport au 1vCore ?
Y'a aucune différence en terme de configuration si je veux héberger un site ou faire un vpn ?
:)
Le C1 est un quad core de 3000 DMIPS en theorie.
le 1vCore est un seul core d'un Xeon E5v3 2,4 Ghz qui a 6 ou 8 core (OVH ne precise pas).
En theorie le C1 a l'avantage CPU, du moins sur les applications 'multi-threadables' (ouch!), mais c'est un ARM donc ca peut poser des problèmes de compatibilité par moment (ou il faut souvent se compiler soi meme les choses donc ca rend l'installation et l'upgrade plus compliqué).
Pour les trucs de base, web par exemple, je ne pense pas que la différence soit flagrante, car ce sont rarement des choses 'cpu bound'.
L'offre Online a plus de débit (200Mbps sur le papier mais en pratique mon C1 fait du 1Gbps...). L'offre OVH est vraiment limité a 100Mbps.
Pour le novice l'offre Online est plus avancée,il y a un catalogue d'applications qu'on peut préinstallées et les volumes s'ajoutent/s'enlevent facilement. L'offre est aussi facturée a la demande avec un plafond (par exemple j'ai recu une facture de 0,42€ pour avoir bidouillé un peu de temps avec un C1 au mois de septembre).
Bref l'offre Online(Scaleway) est plus moderne et plus 'cloudy' que le VPS d'OVH. Mais d'un autre coté c'est pas le concurrent direct. L'offre équivalente chez OVH n'est pas encore sortie et est en 'lab' ici: https://www.runabove.com
-
IPv6 vient d'apparaitre dans le manager de mon VPS...
pas de doc. pas d'info. pas de comm.
a priori c'est un /128 (sigh)... pas de RA donc il faut configurer tout a la main: la gateway est en ::1 du réseau /64 (trouvé par hasard vu que pas de doc).
enfin comment 'promouvoir et bien démarrrer la vie d'IPv6 facon OVH' = en faisant de la merde...sigh
Je reste chez Vultr pour le moment donc.
-
OVH est devenu bien trop grosse comme compagnie, il n'y a plus rien a attendre d'eux maintenant.
-
cali: quelle est la bonne manière ?
IP et routage statique ?
La meme maniere que pour IPv4 (dans ce cas, oui, statique)
Mais je peux comprendre des arguments pour faire autrement (j'en ai meme quelques-uns en tete).
-
La meme maniere que pour IPv4 (dans ce cas, oui, statique)
Mais je peux comprendre des arguments pour faire autrement (j'en ai meme quelques-uns en tete).
Attention, en IPv4, tu as un niveau de moins d'hôte, d'un point de vue routage
IPv4:
- le routeur FAI est directement connecté aux routeurs abonné (qui sont les feuilles de l'arbre), il n'y a rien de plus, les PC ne sont pas dans l'arbre (= derrière le NAT)
IPv6:
- le routeur FAI est directement connecté aux routeurs abonné, toujours, mais les routeurs ne sont plus les feuilles : chaque routeur abonné dispose d'un (ou de plusieurs) subnet, et c'est les PC derrière le routeur qui sont les feuilles de l'arbre
Je ne sais pas si je suis clair
La différence est donc la "délégation" de préfixe, qui existe en v6, et pas en v4 (parce que le v4 n'est plus qu'une version bâtarde d'internet)
-
Je ne sais pas si je suis clair
La différence est donc la "délégation" de préfixe, qui existe en v6, et pas en v4 (parce que le v4 n'est plus qu'une version bâtarde d'internet)
Sur de l'access, oui, je suis d'accord.
Sur du hosting, appliquer le meme modele ca me semble un peu bizarre, mais je peux comprendre qu'il n'y a pas forcement de meilleure alternative.
Ce qui peut deranger certains c'est "DHCP(v6) comme protocole de routage".
-
Ben je ne sais pas justement, si qqn a des bonnes méthodes à partager, je suis preneur ! (y compris pour l'access)
-
DHCPv6-PD meme pour un hote (serveur) me semble le mieux et le plus simple pour tout le monde, des 2 cotés.
Avec l’avènement des containers il faut que le serveur hote puissent 'router IPv6' pour les containers qu'il heberge donc lui attribuer au moins un réseau /63 ou plus me semble une évidence.
Vu qu'en 'pratique', pour le moment, on "préfixe" par pas de 4, un /60 me semble être le minimum syndical.
Orange fournit un /56 sur des millions de connexions grand public, ca n'est donc par un probleme et un très bon exemple a suivre.
Franchement je m'attendais a un /60 en DHCPv6-PD sur les VPS d'OVH. La on a un /128 full manuel , même pas de dhcpv6 alors que l'IPv6 est complètement connu et fixe.
-
C'est le même paramétrage que sur les serveurs dédiés d'OVH : configuration d'IPv6 (adresse+route default) en manuel.
Si la méthode DHCPv6 facilite le paramétrage, elle n'est pas adaptée à un environnement serveur. Jamais personne n'a utilisé DHCP pour configurer IPv4 sur des serveurs, je ne vois pas pourquoi ça changerait en IPv6.
En plus on est en environnement réseau mutualisé, ça fait quelques contre-mesures à mettre en place pour éviter les problèmes.
-
C'est le même paramétrage que sur les serveurs dédiés d'OVH : configuration d'IPv6 (adresse+route default) en manuel.
Si la méthode DHCPv6 facilite le paramétrage, elle n'est pas adaptée à un environnement serveur. Jamais personne n'a utilisé DHCP pour configurer IPv4 sur des serveurs, je ne vois pas pourquoi ça changerait en IPv6.
En plus on est en environnement réseau mutualisé, ça fait quelques contre-mesures à mettre en place pour éviter les problèmes.
hé non, raté :)
le DHCP snooping + IPSG + DAI "de base" est entièrement basé sur le DHCP IPv4 de ton serveur (pas de DHCP = pas d'IPSG = pas de traffic), qui coup de chance pour toi est effectué au boot PXE souvent ;)
envois un DHCP RELEASE sur un switch d'un hébergeur, pas sur que ca se passe bien ;) (chez nous ca kouik ;)
et c'est le moyen le plus rentable en TCAM pour appliquer une sécurité globale sur le VLAN mutu entre serveurs, une conf 100% statique bouffe facilement 2 fois plus de TCAM ...
Mik
-
Franchement je m'attendais a un /60 en DHCPv6-PD sur les VPS d'OVH. La on a un /128 full manuel , même pas de dhcpv6 alors que l'IPv6 est complètement connu et fixe.
OVH reprend les bonnes méthodes Kimsufi. ;D
-
Jamais personne n'a utilisé DHCP pour configurer IPv4 sur des serveurs, je ne vois pas pourquoi ça changerait en IPv6.
euh mais les VPS d'OVH sont configurés en DHCP pour IPv4 par defaut:
en live sur un:
$ cat /etc/network/interfaces.d/eth0.cfg
# The primary network interface
auto eth0
iface eth0 inet dhcp
Et la on parle de DHCPv6-PD (prefix delegation) qui laisse le choix a l'admin du serveur de son plan d'adressage. Ca permet juste de recup automatiquement le préfixe.
On retrouve un des problèmes majeurs de l'adoption d'IPv6: de l'incompétence et des gens raisonnent comme si c'était IPv4 avec des adresses différentes et se contentent de transposer plus ou moins (souvent moins) ce qu'ils faisaient en IPv4. Alors que tout a été repensé pour simplifier et mieux faire les choses (comme DHCPv6-PD par exemple).
Il faudrait vraiment que les admins réseaux et autres ingés/designers/whatever fassent un effort de formation et compréhension d'IPv6.
-
@mirtouf c'est un /128 sur leskimsufi ?
@mikmak
IPSG = ?
Chez Online, DHCP et DHCPv6 distribuent les IP aux serveurs ?
C'est le switch l'option permettant d'identifier le client ?
-
IPSG = ?
IP source guard
De l'anti IP spoofing basé sur le dhcp snooping, si je ne m'abuse
-
Chez Ikoula, l'IPv4 est dans l'IPv6 et chaque client à un /112 :
Comment calculer mon IPv6 avec mon IP actuelle
Ceci est applicable pour tous les serveur dédié physiques ou virtuelles.
L'ipv6 se calcul de la manière suivante :
2a00 :c70 :1 :XXX :XXX :XXX :XXX : YYYY /96 où
- « XXX:XXX:XXX:XXX : » sera l’adresse IPv4 actuelle de votre serveur
- « YYYY » sont vos adresses disponibles allant de 0000 à FFFF
L’adresse de votre passerelle sera 2a00:c70:1:XXX:XXX:XXX::1
Source : https://support.ikoula.com/index-1-2-219-2564-IPV6-serveur-d%C3%A9di%C3%A9%20calcule.html
Concrètement, comme c'est pas super intuitif, un exemple est plus parlant :
# The primary network interface
auto p4p1
iface p4p1 inet static
address 213.246.163.115
netmask 255.255.255.0
gateway 213.246.163.1
dns-nameservers 213.246.33.144 213.246.36.14 80.93.83.11 80.93.83.25
iface p4p1 inet6 static
address 2a00:c70:1:213:246:163:115:2
netmask 96
gateway 2a00:c70:1:213:246:163::1
-
@mirtouf c'est un /128 sur leskimsufi ?
@mikmak
IPSG = ?
Chez Online, DHCP et DHCPv6 distribuent les IP aux serveurs ?
C'est le switch l'option permettant d'identifier le client ?
IPSG = IP source guard, c'est en gros comme une ACL "dynamique" sur le port qui check l'IP source des paquets
DAI = dynamic ARP inspection, le process qui vérifie les paquets ARP et qui matchent que la MAC + IP ca colle bien avec l'entrée DHCP
en IPv4 l'ID c'est la mac address pour du DHCP oui, couplé à un port-security sur le port pour bloquer les MACs non validées par notre SI.
c'est un ptit peu moins vrai depuis qu'on a fait nos propres switchs qui nous permettent de (bcp) simplifier la sécurisation :
sur un switch constructeur, dans 99% des cas, ils sont basés sur du learning dynamique (apprendre les MACs qui poppent sur les ports de switchs, associés les IPs grace au DHCP, etc etc) (et pour passer ca en statique, c'est juste galère et pas prévu pour <= non les "learning disable" des switchs, c'est une grosse blaque hein ;)
quand on maitrise 100% du switch, dans un environnement maitrisé (VLANs/serveurs), on s'en fout à 200% du learning auto, on préfère pousser une conf et donc par exemple dire "tel port = tel mac + telle IP + tel VLAN", pas besoin de l'apprendre quand le serveur/OS démarre, on le sait d'avance, ca évite des broadcasts inutiles "ou quelle est la MAC machine" ou des comportemtents de switchs foireux du type "ha j'ai pas trouvé la mac de telle IP, bon ben je vais balancer partout, au cas où ca interesse qq'un" (très bonne idée quand une IP se fait DDoS par ex et que l'OS a crashé ;)
en IPv6, l'ID enfin "DUID" est de type LLT (iirc), donc un truc non basé sur la MAC ce qui permet à un client de déplacer son subnet sur le serveur/VM de son choix
il y a pas mal d'avantages au DHCPv6-PD, personnellement je vois la chose comme suit :
on alloue un /48 par client
le client découpe en /56 par serveurs
il devrait en théorie faire une requete DHCPv6-PD par serveur pour récupérer son /56
à sa charge de router ses sous-subnets (/64 par ex) dans ses VMs, tunnels whatever depuis ce serveur
en cas de besoin, il peut basculer une VM ailleurs, et y refaire un DHCPv6-PD pour récupérer le(s) /64 qui vont bien sur le nouveau serveur (pour moi c'est un mode "secours", sinon il déplace le /56 directement), il peut meme faire une requete DHCPv6 pour son /48 complet et avoir un serveur dédié a des bascules de backup par exemple, bref, on peut désigner de plusieurs manières son réseau sans polluer de routes statiques les routeurs et gérer une infra de déploiement
l'objectif est de limiter la segmentation IPv6, c'est sans doute pas parfait, mais c'est quand meme franchement plus clean d'un point de vue techo que des "ipv6 route xxxx/64" sur tous les routeurs, on a un protocole fait pour ca autant l'utiliser (bon les clients ont été loooongtemps bien buggés comme il faut mais bon ...)
après pour ceux qui ralent des /128 sur les VPS , je pense qu'ils oublient un peu vite qu'il faut une base pour router des subnets, donc déjà avoir un endpoint qui ping, c'est un pas en avant ;)
Mik
-
chez Vultr, c'est un /64 par serveur: libre a l'admin de le configurer comme il souhaite et la gateway s'obtient par discovery:
(https://s14.postimg.org/ukcqmciwx/vultr.png)
(on peut avoir le prefix via leur API si besoin)
A comparer a l'interface d'OVH qui fait penser au début du l'Internet... :P
-
après pour ceux qui ralent des /128 sur les VPS , je pense qu'ils oublient un peu vite qu'il faut une base pour router des subnets, donc déjà avoir un endpoint qui ping, c'est un pas en avant ;)
pas besoin de 'base' avec IPv6 tu peux utiliser les link-local entre la gw et le vps pour router.
vu de l'ISP, il y a une seule route le /64 (ou le /56) vers la link-local du serveur. point. exactement comme fait Orange en IPv6 pour ses box.
c'est plus simple et l'ISP ne connait même pas le plan d'adressage du client (quelle IP du /64 ou /56 est son entrypoint/endpoint) : il s'en tape en fait.
-
le truc qui conf en RA c'est loin d'etre la panacée pour les fournisseurs de VPS et de serveurs ...
déjà en tant qu'hébergeur tu as la *responsabilité* de savoir qui utilise telle IP à un instant donné.
c'est loin d'etre simple avec de l'autodynamique-a-la-volée ...
perso, je prefere pousser une conf depuis mon SI ;)
Mik
-
déjà en tant qu'hébergeur tu as la *responsabilité* de savoir qui utilise telle IP à un instant donné.
C'est pour ça que les RA, sauf dans ton LAN chez toi, non merci
-
bon les clients ont été loooongtemps bien buggés comme il faut mais bon ...
Vous utilisez quoi, comme serveur ?
-
on conf pas l'adresse en RA mais juste la gateway.
Encore une fois il faut vraiment que les gens approfondissent plus leur connaissances d'IPv6 au dela de l'intro en 1 heure sur autoconf/ra/rs... :P
-
oue enfin router sur une link local, d'un point de vue clareté , on a vu mieux ...
@jack: ISC depuis 1 ou 2 ans (dibbler avant mais plus trop maintenu de nos jours parce qu'on dev un truc pas plus maintenu/dev ... l'opensource, la joie ;)
Mik
-
Encore une fois il faut vraiment que les gens approfondissent plus leur connaissances d'IPv6 au dela de l'intro en 1 heure sur autoconf/ra/rs... :P
Tu peux faire des l'allocation de ressources via SLAAC ?
Si tu as des docs, ça m'intéresse
C'est rigolo, je croyais que c'était pour ça que, finalement, dhcpv6 a été fait :)
-
Tu peux faire des l'allocation de ressources via SLAAC ?
Si tu as des docs, ça m'intéresse
C'est rigolo, je croyais que c'était pour ça que, finalement, dhcpv6 a été fait :)
on parlais pas d'allocation de ressources la mais de configurer la gateway.
je crois que ne se comprend plus ou qu'on parle plus des memes choses depuis quelques postes la...
oue enfin router sur une link local, d'un point de vue clareté , on a vu mieux ...
On parle d'automatisation complète donc que ce soit des link-local ou des global ca change rien en terme de clareté...ca reste des IPv6...
apres c'est sur qui s'il faut se taper des link-local a la main c'est autre chose.
-
je crois que ne se comprend plus ou qu'on parle plus des memes choses depuis quelques postes la...
Peut-être en effet :)
Ce que j'ai besoin, c'est :
- attribuer le même subnet au même "client", de manière fiable, reproductible et connue
- router ce subnet via des IPv6 globalement addressables et globalement routables
Du coup, pour faire ça, le SLAAC ne me parait pas du tout adapté, d'où le dhcp
-
oue enfin router sur une link local, d'un point de vue clareté , on a vu mieux ...
@jack: ISC depuis 1 ou 2 ans (dibbler avant mais plus trop maintenu de nos jours parce qu'on dev un truc pas plus maintenu/dev ... l'opensource, la joie ;)
Mik
Utiliser du DHCPv6 avec le Prefix delegation comme vous le faites chez online.net c'est grave de la cheap crap. J'ai encore du mal à comprendre pourquoi il y en a autant qui utilise cette merde. OVH aussi fait ça maintenant alors qu'avant ils savaient faire du routage proprement.
-
Utiliser du DHCPv6 avec le Prefix delegation comme vous le faites chez online.net c'est grave de la cheap crap. J'ai encore du mal à comprendre pourquoi il y en a autant qui utilise cette merde. OVH aussi fait ça maintenant alors qu'avant ils savaient faire du routage proprement.
avec des arguments aussi étoffés, on se doute bien que tu as raison ;)
Mik
-
Cali, quelle est la bonne méthode, selon toi ?
-
Cali, quelle est la bonne méthode, selon toi ?
Bien tu rajoutes une route dans la table de routage ? Et si tu veux que le « client » puisse le faire lui-même je vois pas ce qui empêche de faire un panneau de contrôle...
-
Ok, donc toi, tu as des routes machin/48 via interco
Et sur le routeur client récupère l'IP d'interco + le subnet par une méthode magique
Du coup, j'veux bien que tu me détailles la méthode magique, incluant les protections anti-spoofing / poisonning :)
-
Ok, donc toi, tu as des routes machin/48 via interco
Et sur le routeur client récupère l'IP d'interco + le subnet par une méthode magique
Du coup, j'veux bien que tu me détailles la méthode magique, incluant les protections anti-spoofing / poisonning :)
tu te compliques la vie, laisse donc le telnet sur ton routeur ouvert, le client fera la conf et hop ;)
Mik
-
Ok, donc toi, tu as des routes machin/48 via interco
Et sur le routeur client récupère l'IP d'interco + le subnet par une méthode magique
Du coup, j'veux bien que tu me détailles la méthode magique, incluant les protections anti-spoofing / poisonning :)
Non, c'est juste statique... Le client a toutes les informations pour configurer sa machine.
Par exemple nous avons une installation qui fonctionne sur des sous-réseaux en /64 non-routés, le routeur utilise .1 et chaque machine sur le segment à une adresse dans le sous-réseau. Si un utilisateur souhaite un sous-réseau routé, à savoir un /56 ou /48 alors le routeur rajoute une route vers l'IPv6 du /64 de la machine. Les switchs connaissent les MACs des machines autorisées à transmettre et c'est la même chose du côté du routeur...
-
Non, c'est juste statique... Le client a toutes les informations pour configurer sa machine.
Ok, ça ne me convient pas pour mon cas d'utilisation, mais ça peut-être une solution pour des serveurs
Par exemple nous avons une installation qui fonctionne sur des sous-réseaux en /64 non-routés, le routeur utilise .1 et chaque machine sur le segment à une adresse dans le sous-réseau. Si un utilisateur souhaite un sous-réseau routé, à savoir un /56 ou /48 alors le routeur rajoute une route vers l'IPv6 du /64 de la machine. Les switchs connaissent les MACs des machines autorisées à transmettre et c'est la même chose du côté du routeur...
Ça par contre ..
Actuellement, j'ai un domaine de broadcast avec environ 1000 nodes IPv6
Si j'ai bien compris, il est donc nécessaire, sur mon routeur, de faire des ACL comme ceci:
- autoriser le trafic from: mac to: ipv6
- autoriser le trafic from: mac to: subnet-v6
Et sur tout les switch, au plus prêt du client donc, je rajoute des ACL restreignant le NDP au seul couple IP-mac du client associé au port
Et tout ça .. via cron + ssh ?
Ça me parait viable pour 10 nodes, difficiles sinon, et surtout extrêmement contraignant
-
Actuellement, j'ai un domaine de broadcast avec environ 1000 nodes IPv6
Si j'ai bien compris, il est donc nécessaire, sur mon routeur, de faire des ACL comme ceci:
- autoriser le trafic from: mac to: ipv6
- autoriser le trafic from: mac to: subnet-v6
Et sur tout les switch, au plus prêt du client donc, je rajoute des ACL restreignant le NDP au seul couple IP-mac du client associé au port
Et tout ça .. via cron + ssh ?
Ça me parait viable pour 10 nodes, difficiles sinon, et surtout extrêmement contraignant
C'est pas exactement comme ça qu'on fait mais ça fonctionne très bien pour bien plus que 1000 « nodes ». Personne ne se plaint vraiment, après c'est peut-être parce qu'on vise majoritairement un public avisé. Mais on fournit aussi des services à des gens qui n'ont pas les connaissances et ça fonctionne aussi très bien. Par contre je vois beaucoup de posts de gens qui rencontrent pas mal de problèmes avec l'IPv6 chez online.net.
Aussi aborder la securité quand on voit la gueule des implèmentations du DHCPv6 ça me fait un peu marrer... Elles sont toutes buggées et j'ose même pas imaginer le nombre de 0days qu'il doit y avoir...
-
C'est pas exactement comme ça qu'on fait
Ben explique moi, ça m'intéresse vraiment tout ça
-
Ben explique moi, ça m'intéresse vraiment tout ça
Déjà pourquoi tu veux utiliser des ACLs ? Pas besoin d'ACLs, côté routeur il y a la table NDP, côté commutateur le filtrage MAC, pourquoi le commutateur devrait faire du NDP ?
-
Déjà pourquoi tu veux utiliser des ACLs ? Pas besoin d'ACLs, côté routeur il y a la table NDP, côté commutateur le filtrage MAC, pourquoi le commutateur devrait faire du NDP ?
Ben heu, comment est-ce que je valide que le NDP provient bien du bon client ?
Et, heu, comment j'empêche l'IP spoofing ? Et le poisonning ?
-
Ben heu, comment est-ce que je valide que le NDP provient bien du bon client ?
Et, heu, comment j'empêche l'IP spoofing ? Et le poisonning ?
Si il y a filtrage MAC sur le commutateur et que le routeur à l'adresse MAC dans sa table NDP, c'est quoi le problème ?
-
Si moi, from ma mac, je dis à tout le monde que j'ai l'IP du voisin, ça pose problème
Parce que tout le monde va m'envoyer, à moi, le trafic destiné au voisin
ARP poisonning en ipv4, j'imagine que tu peux faire pareil en NDP, c'est fascinant et particulièrement amusant
-
Si moi, from ma mac, je dis à tout le monde que j'ai l'IP du voisin, ça pose problème
Parce que tout le monde va m'envoyer, à moi, le trafic destiné au voisin
ARP poisonning en ipv4, j'imagine que tu peux faire pareil en NDP, c'est fascinant et particulièrement amusant
Je comprends pas comment tu fais pour recevoir le trafic du voisin, parce que tu peux pas spoofer son adresse MAC vu que le switch t'autorise pas à le faire et le routeur connait la MAC du voisin...
-
Cela me rappelle une anecdote,ou je me suis fais souffler dans les bronches par OVH,parce qu'un gars de mon équipe avait utilisé un proxyarp avec la MAC du routeur,et que toute la baie était tombée. ::)
-
N'importe qui faisant ça sur un réseau se fera souffler dans les bronches par le netadmin :D
J'ai coupé des users pour moins que ça.
-
@mirtouf c'est un /128 sur les kimsufi ?
Oui, depuis quelques années...
@mikmak
Les joies du client dibbler qui n'arrivait pas à recevoir de réponse du serveur DHCP... que d'émotions ! Je n'oublierai pas non plus que le client dibbler perdait un peu les pédales si on mettait en place un bridge sur son interface réseau. Depuis que Online est passé sur ISC dhcp, je n'ai plus à me plaindre.
Il reste encore à savoir si du côté de Windows le DUID peut se configurer autrement qu'en bidouillant la base de registre.
-
Eh sinon, il y a bien longtemps, on avait inventé un protocole qui s'appelait ES-IS (ISO9542). Non, pas IS-IS, mais la version host - routeur.
Ça permettait de multihomer des hosts facilement sans vrrp/hsrp, ou même d'annoncer des routes "service" depuis les serveurs, très similaire à ce qui se fait désormais avec le bgp jusqu'au ToR.
Ça aurait peut-être été une bonne idée de le ressusciter et de l'adapter, de la même manière qu'IS-IS, à IPv6, plutôt que d'avoir plein de routeurs qui annoncent en ra une gw par exemple...
-
Quelqu'un dans l'assistance a-t-il déjà testé Kea dhcp (que ce soit côté client ou serveur) ?
-
Eh sinon, il y a bien longtemps, on avait inventé un protocole qui s'appelait ES-IS (ISO9542). Non, pas IS-IS, mais la version host - routeur.
Ça permettait de multihomer des hosts facilement sans vrrp/hsrp, ou même d'annoncer des routes "service" depuis les serveurs, très similaire à ce qui se fait désormais avec le bgp jusqu'au ToR.
Ça aurait peut-être été une bonne idée de le ressusciter et de l'adapter, de la même manière qu'IS-IS, à IPv6, plutôt que d'avoir plein de routeurs qui annoncent en ra une gw par exemple...
De base, si un host supporte IPv6 il supporte ra. en plus c'est ultra simple a configurer coté host.
Pas sur que les os supporteraient ton es-is s'il était adapté a IPv6 et si oui avec quelle complexité supplèmentaire pour l'admin du host ?
et en quoi est-ce gênant qu'un routeur annonce une gw en ra ?
-
Ce que j'ai besoin, c'est :
- attribuer le même subnet au même "client", de manière fiable, reproductible et connue
- router ce subnet via des IPv6 globalement addressables et globalement routables
Si tu veux faire ca cote access, regarde cote Ericsson/RedBack la fonctionalite appelee CLIPS.
GW via RA, WAN CPE (si tu en as besoin) via SLAAC ou DHCPv6 (selon la conf cote RA), delegation de prefix via DHCPv6. Tout part d'une base RADIUS, configuration minimale (uniquement les ports/circuits d'arrivee) sur le BNG.
Ca marche de la meme facon en PPPoE (avec login/pass classique) et IPoE (login = MAC addr, pass = configure sur le BNG).
Cote hebergement, c'est pas impossible d'utiliser le meme modele, ca semble juste un peu bizarre.
Il y a d'ailleurs d'autres choses qui peuvent etre bizarres meme en mode acces, mais finalement sont des fonctionalites tres utiles.
-
Ben heu, comment est-ce que je valide que le NDP provient bien du bon client ?
Et, heu, comment j'empêche l'IP spoofing ? Et le poisonning ?
Subscriber management. Le BNG devient plus qu'un simple routeur, et authorize pas mal de choses via RADIUS (ARP/ND, DHCP(v6), routage tout betement, ....).
-
Si moi, from ma mac, je dis à tout le monde que j'ai l'IP du voisin, ça pose problème
Private VLAN et/ou VPLS hub-and-spoke, et tout remonte a un point unique.
Par contre je suis d'accord que les equipements ne sont plus les memes.
ARP poisonning en ipv4, j'imagine que tu peux faire pareil en NDP, c'est fascinant et particulièrement amusant
Memes problemes, meme solutions.
-
Quelqu'un dans l'assistance a-t-il déjà testé Kea dhcp (que ce soit côté client ou serveur) ?
Oui, cote serveur.
Cote feed-back, a suivre, ca fait pas encore un mois qu'il est en prod, mais pour l'instant ca a l'air stable.
-
C'est confirmé, c'est un /128 pour les VPS d'OVH. sigh :o
Je viens de recevoir un mail avec un lien vers la 'doc' de configuration : https://www.ovh.com/fr/g2365.ipv6
La config est statique uniquement avec gateway statique aussi. re sigh.
C'est le minimum syndical donc. A croire qu'il n'ont pas compris l’intérêt d'IPv6...
-
Ils ont fait pareil qu'Online avec Scaleway en fait.
-
Y a-t-il besoin de plus d'une IPv6 pour un VPS, après ?
-
C'est bien pratique pour pleins de chose, par exemple faire des VPN/tunnels proprement.
-
Et si justement le but etait de décourager ça ?
-
Attention, en IPv4, tu as un niveau de moins d'hôte, d'un point de vue routage
IPv4:
- le routeur FAI est directement connecté aux routeurs abonné (qui sont les feuilles de l'arbre), il n'y a rien de plus, les PC ne sont pas dans l'arbre (= derrière le NAT)
IPv6:
- le routeur FAI est directement connecté aux routeurs abonné, toujours, mais les routeurs ne sont plus les feuilles : chaque routeur abonné dispose d'un (ou de plusieurs) subnet, et c'est les PC derrière le routeur qui sont les feuilles de l'arbre
Je ne sais pas si je suis clair
La différence est donc la "délégation" de préfixe, qui existe en v6, et pas en v4 (parce que le v4 n'est plus qu'une version bâtarde d'internet)
Dit de façon plus rigoureuse :
- un "routeur" IPv4 type box est un NAT-routeur, pas un routeur normal
- un routeur IPv6 type box est un routeur normal (mais en moins configuration en général)
Un NAT-routeur a deux cotés : l'intérieur et l'extérieur, il n'est pas symétrique :
- vu de l'intérieur, c'est un routeur (ou "passerelle")
- vu de l'extérieur, c'est un hôte.
-
Et si justement le but etait de décourager ça ?
Aucune idée, faudrait poser la question. :P Je pense quand même que ce n'est pas ce qui va arrêter la majorité des gens intéressés par un VPN/tunnel, je doute qu'IPv6 soit leur priorité.
-
Y a-t-il besoin de plus d'une IPv6 pour un VPS, après ?
oui.
Déjà on peut mettre l'acces SSH sur sa propre adresse IPv6 qui ne sert qu'a cela. On peut ouvrir des acces backup/monitoring/admin sur d'autres IPs plutot que tout faire sur la meme.
On peut avoir une IP par 'service' plutôt que devoir multiplexer ou changer de ports: si j’héberge 2 sites web sur mon vps j'utilise 2 ip avec les ports 80/443. Cela isole les 2 serveurs web (et en plus je peux avoir un Apache et un NGinx par exemple) plutot que de faire du virtual web hosting avec un seul serveur (name based hosting par exemple).
Si on utilise les containers il faut au moins un /64 de toute facon (doc (https://docs.docker.com/engine/userguide/networking/default_network/ipv6/)) . Meme si on ne fait tourner qu'un seul container. Avec un /128 impossible d'avoir des containers qui communiquent en IPv6.
Un VPS avec 1 container c'est très pratique a administrer, OVH fait meme sa comm avec ca et pourtant ca ne marche pas.
Mais surtout pourquoi se limiter a ce qu'on avait en IPv4 (une IP public par machine) alors que l’intérêt n°1 d'IPv6 c'est justement d'avoir autant d'adresses qu'on veut. Ca va a l'encontre de toute innovation: je vous met IPv6 mais surtout ne faite rien de nouveau avec ca, je vous restreint a ce que vous pouviez faire en IPv4.
-
Mentalité de commerçant de beluga qui se met au commerce du sable au Sahara.
-
C'est confirmé, c'est un /128 pour les VPS d'OVH. sigh :o
C'est déjà mieux que rien...
J'ai gardé un VPS de 2014 (qui me sert de relais SMTP entrant/sortant vu que chez Orange le port 25 est bloqué en sortie...) uniquement parce que j'ai une IPv6 dispo... Du coup il tourne avec une Ubuntu 14.04 et j'aimerais prendre un nouveau VPS pour passer sur une distrib maintenue sans coupure de service, mais je veux de l'IPv6 absolument.
Autre question: Les VPS 2016 supportent IPSEC ? Parce que sur les 2014 la réponse est non, donc je passe par un openvpn qui n'est pas offloadé sur l'ERL...
Sinon je change de crèmerie (et je passe chez vultr par exemple qui semble être OK pour IPSEC).
-
Pour passer à Ubuntu server 16.04 LTS :
sudo do-release-upgrade
Sinon, Ubuntu 14.04 est encore maintenu (mises à jour de sécurité) jusqu'à fin avril 2019.
Il y a encore quelques jours, Ubuntu 14.04 avait une part de marché plus importante que Ubuntu 16.04 :
(https://lafibre.info/testdebit/ubuntu/201609_ubuntu_graph.png)
Les stats d'hier (cf http://fr.archive.ubuntu.com/stats/ )
- Ubuntu 17.04 : .007% (43 separate computers)
- Ubuntu 16.10 : 1.544% (9417 separate computers)
- Ubuntu 16.04 LTS: 43.095% (262810 separate computers)
- Ubuntu 15.10 : 1.686% (10284 separate computers)
- Ubuntu 15.04 : 1.357% (8278 separate computers)
- Ubuntu 14.10 : .617% (3767 separate computers)
- Ubuntu 14.04 LTS: 33.130% (202043 separate computers)
- Ubuntu 13.10 : .715% (4365 separate computers)
- Ubuntu 13.04 : .600% (3663 separate computers)
- Ubuntu 12.10 : .353% (2155 separate computers)
- Ubuntu 12.04 LTS: 12.887% (78595 separate computers)
- Ubuntu 11.10 : .391% (2388 separate computers)
- Ubuntu 11.04 : .358% (2186 separate computers)
- Ubuntu 10.10 : .138% (844 separate computers)
- Ubuntu 10.04 LTS: 2.651% (16172 separate computers)
- Ubuntu 9.10 : .096% (587 separate computers)
- Ubuntu 9.04 : .051% (315 separate computers)
- Ubuntu 8.10 : .018% (113 separate computers)
- Ubuntu 8.04 LTS: .258% (1577 separate computers)
- Ubuntu 7.10 : .006% (39 separate computers)
- Ubuntu 7.04 : .009% (55 separate computers)
- Ubuntu 6.10 : .001% (12 separate computers)
- Ubuntu 6.06 LTS: .019% (121 separate computers)
- Ubuntu 5.10 : 0% (6 separate computers)
- Ubuntu 5.04 : 0% (1 separate computers)
- Ubuntu 4.10 : 0% (0 separate computers)
-
Tiens, 17.04 ? J'avais pas encore vu le nom, Zesty donc :)
-
Pour passer à Ubuntu server 16.04 LTS :
sudo do-release-upgrade
Sinon, Ubuntu 14.04 est encore maintenu (mises à jour de sécurité) jusqu'à fin avril 2019.
En fait je me suis trompé, c'est une 14.10...
Sinon pour l'Upgrade je suis au courant, mais le forum D'OVH est plein de témoignages de mise à jour ratées pour les vps installés à partir des images Ubuntu fournies par OVH, donc vu les prix je préfère prendre un second vps, le configurer puis basculer mon mx dessus.
-
OK
Pour info, il est encore possible de faire l'upgarde, la 15.04 et la 15.10 ne sont plus maintenus, mais sont encore présentes sur les serveurs (pour passer de la 14.10 à la 16.04, il faut faire 14.10=>15.04=>15.10=>16.04)
La 15.04 devait être supprimé des serveurs à la fin du mois il me semble et la 15.10 fin avril 2017.
Les upgrades qui sautent les version ne sont possibles que de LTS en LTS (donc 10.04 LTS => 12.04 LTS => 14.04 LTS => 16.04 LTS => 18.04 LTS)
-
Autre question: Les VPS 2016 supportent IPSEC ? Parce que sur les 2014 la réponse est non, donc je passe par un openvpn qui n'est pas offloadé sur l'ERL...
A priori je dirais oui. Tout comme pour Docker qui était mal supporté sur les 2014 car ceux-ci utilisaient OpenVZ.
Les 2016 sont basés sur OpenStack et ca fonctionne ok.
Je n'ai pas testé de faire un serveur ipsec vpn mais les "modprobe" pour ipsec sont la.
Apres si t'as le choix en Vultr et OVH...perso le choix est vite fait... c'est Vultr.
-
Effectivement, en IPv6, un /128 sur un VPS "de base" chez OVH.
C'est marrant, dans leur doc sur https://www.ovh.com/fr/g2365.ipv6 il y a un lexique qui parle de IPv6_PREFIX = le préfixe de votre bloc IPv6, mais rien plus loin.
Et pour récupérer la gateway, il faut passer par l'API, ce n'est pas sur la page de management. Pas de firewall non plus, ça sent un peu la pièce rajoutée.
Et on peut ajouter des adresses Ipv4 geolocalisées depuis le management, mais pas d'IPv6.
Mais bon, ça fonctionne. Ça suffit pour ce que je veux en faire :)
-
Bonjour
je cherche comment activé l'ipv6
l ip v6 est donné 2001:41d0:401:xx::xx
et le gataways v6 egalement 2001:41d0:401:xx::1
ah oui OS est ubuntu 16.10 sur vpsovh
j'ai beau suivre le guide ça donne rien
merci de votre aide
-
Toujours la même chose :
Qu'est-ce que tu as fait, qu'est-ce que tu as constaté?
-
j'ai mis ça dans etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback
# Source interfaces
# Please check /etc/network/interfaces.d before changing this file
# as interfaces may have been defined in /etc/network/interfaces.d
# See LP: #1262951
source /etc/network/interfaces.d/*.cfg
iface eth0 inet6 static
address 2001:41d0:401:xx::2
netmask 128
post-up /sbin/ip -6 route add 2001:41d0:401:xxx::1 dev eth0
post-up /sbin/ip -6 route add default via 2001:41d0:401:xxx::1 dev eth0
pre-down /sbin/ip -6 route del default via 2001:41d0:401:xxx::1 dev eth0
-
Si quelqu'un a une réponse, j'ai le même souci sur le VPS d'un client...
-
j'ai ca dans un VPS OVH (au Canada mais ca doit être pareil en France):
root@********:~# cat /etc/network/interfaces.d/eth0.cfg
# The primary network interface
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 static
address 2607:gggg:gggg:****:0:0:0:ff5
netmask 128
post-up /sbin/ip -6 route add 2607:gggg:gggg:gggg::1 dev eth0
post-up /sbin/ip -6 route add default via 2607:gggg:gggg:gggg::1 dev eth0
pre-down /sbin/ip -6 route del default via 2607:gggg:gggg:gggg::1 dev eth0
pre-down /sbin/ip -6 route del 2607:gggg:gggg:gggg::1 dev eth0
il faut ajouter une route pour dire que la gateway est joignable sur eth0 puis une route pour dire que la gateway est la route par defaut.
-
Bonsoir,
Êtes-vous bien certain de l'adresse ::2 dans la ligne ci-dessous ?
address 2001:41d0:401:xx::2
À part ce détail, l'extrait de /etc/network/interfaces semble correct, pour être parfaitement rigoureux il manque une ligne pre-down pour supprimer la route vers la passerelle, comme dans l'exemple de kgersen, mais ce n'est probablement pas ça qui vous pose problème.
Pour permettre de comprendre ce que vous entendez par "ça donne rien", pouvez-vous poster ici la sortie des commandes "/sbin/ip -6 addr" et "/sbin/ip -6 route", et expliquer le comportement que vous constatez (et en quoi il diffère de ce que vous attendez) ?
Bonne soirée
-
et pas oublier de rebooter ou faire:
ifdown eth0 && ifup eth0
-
Bonsoir,
Êtes-vous bien certain de l'adresse ::2 dans la ligne ci-dessous ?
À part ce détail, l'extrait de /etc/network/interfaces semble correct, pour être parfaitement rigoureux il manque une ligne pre-down pour supprimer la route vers la passerelle, comme dans l'exemple de kgersen, mais ce n'est probablement pas ça qui vous pose problème.
Pour permettre de comprendre ce que vous entendez par "ça donne rien", pouvez-vous poster ici la sortie des commandes "/sbin/ip -6 addr" et "/sbin/ip -6 route", et expliquer le comportement que vous constatez (et en quoi il diffère de ce que vous attendez) ?
Bonne soirée
voici ceux que j'obtiens
root@vpsxxxx:~# /sbin/ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::f816:3eff:feec:1792/64 scope link
valid_lft forever preferred_lft forever
3: as0t0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 200
inet6 fe80::704b:52a7:afcd:8a61/64 scope link flags 800
valid_lft forever preferred_lft forever
4: as0t1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 200
inet6 fe80::261b:efda:a3e3:f543/64 scope link flags 800
valid_lft forever preferred_lft forever
root@vpsxxxx:~# /sbin/ip -6 route
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev as0t0 proto kernel metric 256 pref medium
fe80::/64 dev as0t1 proto kernel metric 256 pref medium
-
Donc déjà, manifestement, le nom de ton interface est ens3 et pas eth0 (merci systemd :P)
-
Donc déjà, manifestement, le nom de ton interface est ens3 et pas eth0 (merci systemd :P)
C'est effectivement très pénible le nommage des interfaces, chez moi par exemple c'est enp2s0, ils pouvaient pas trouver plus simple ? ::)
C'était tellement mieux ethX :-[
Y'aurait pas moyen qu'ils le modifient dans les prochaines versions ?
Ce que je trouve bizarre c'est que c'est aussi inclus dans debian 8 et j'ai toujours le nommage traditionnel.
-
C'est inclus dans Debian 9, pas dans Debian 8.
-
/me n'a pas de nom hideux sur ses machines
-
merci ya du mieux mais c'est toujours pas ça
# See LP: #1262951
source /etc/network/interfaces.d/*.cfg
iface ens3 inet6 static
address 2001:41d0:401:xxx::xx
netmask 128
post-up /sbin/ip -6 route add 2001:41d0:401:xxx::1 dev ens3
post-up /sbin/ip -6 route add default via 2001:41d0:401:xxx::1 dev ens3
pre-down /sbin/ip -6 route del default via 2001:41d0:401:xxx::1 dev ens3
pre-down /sbin/ip -6 route del 2001:41d0:401:xxx::1 dev ens3
ip -6 addr show ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:41d0:401:xxxx::xx/128 scope global
valid_lft forever preferred_lft forever
inet6 2001:41d0:401:xxxx::1/128 scope global tentative dadfailed
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:feec:1792/64 scope link
valid_lft forever preferred_lft forever
-
C'est inclus dans Debian 9, pas dans Debian 8.
Pourtant chez moi il est bien installé, j'ai des fichiers de conf dans /etc/systemd. Et quand je fais un apt-get install il veut me mettre à jour libsystemd0 systemd et systemd-sysv.
Ou alors il doit pas être utilisé, je pense que c'est plutôt ça.
Il a du sûrement venir avec un autre programme en dépendance car je ne l'ai jamais installé explicitement.
-
La nouvelle notation des interfaces sera incluse dans Debian 9, si tu préfères.
Sinon cette merde est tellement inutile, que quand j'ai rajouté une carte 4*1Gb/s dans mon serveur, le nom de ma première interface a changé (ce qui a niqué toute la conf réseau)
-
C'est vrai que j'ai aussi du mal à m'y faire >:(
Heureusement, j'ai que 2 interfaces dans mon cas.
Sinon j'ai trouvé ça sur wiki :
Debian propose systemd dans ses dépôts (stable, testing, unstable) où il est possible de le mettre comme système d'initialisation par défaut; il est activé par défaut dans la version 8 surnommée Jessie, sortie en 2015
-
Sinon cette merde est tellement inutile, que quand j'ai rajouté une carte 4*1Gb/s dans mon serveur, le nom de ma première interface a changé (ce qui a niqué toute la conf réseau)
Le plus rigolo, c'est qu'ils ont changé le nommage des interfaces exactement pour éviter ce genre de problème...
-
Les "predictable network interface names" peuvent se désactiver pour revenir aux noms plus traditionalistes (eth0,etc)
Suivant les distribs la manip peut varier:
- soit il faut modifier la ligne GRUB_CMDLINE_LINUX dans etc/default/grub et y a ajouter "net.ifnames=0 biosdevname=0" puis faire un "update-grub" et rebooter.
- sinon voir http://askubuntu.com/a/628504 (c'est pour activer donc faire l'inverse).
-
Bonjour
j'ai réussi à activer l ipv6 même après reboot ça fonctionne :D
iface lo inet loopback
iface ens3 inet6 static
address 2001:41d0:401:xxxx::xx
netmask 128
post-up /sbin/ip -f inet6 route add 2001:41d0:401:xx::1 dev ens3
post-up /sbin/ip -f inet6 route add default via 2001:41d0:401:xx::1 dev ens3
pre-down /sbin/ip -f inet6 route del 2001:41d0:401:xx::1 dev ens3
pre-down /sbin/ip -f inet6 route del default via 2001:41d0:401:xx::1 dev ens3
-
Le plus rigolo, c'est qu'ils ont changé le nommage des interfaces exactement pour éviter ce genre de problème...
Je sais bien ! :/
-
Le plus rigolo, c'est qu'ils ont changé le nommage des interfaces exactement pour éviter ce genre de problème...
Lennart Poettering n'est pas vraiment reconnu pour avoir de "bonnes" idées sur l'avenir de Linux.
Et c'est toute la sphère Linux qui en pâtit.
Demi (http://forum-images.hardware.fr/images/perso/2/s@ms.gif).