Bonjour,
- Je souhaite configurer netplan sans DHCP.
- IPv4 seulement, IPv6 ne m’intéresse pas tant que que le routage FO ne sera pas supporté par OVH
La configuration d'origine est :
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 2001:41d0:700:1f6d::/64
dhcp4: true
gateway6: 2001:41d0:700:1fff:ff:ff:ff:ff
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 2001:41d0:3:163::1
routes:
- to: 2001:41d0:700:1fff:ff:ff:ff:ff/128
via: '::'
set-name: eno1
De ce que j'en comprends IPv6 est en static et IPv4 en DHCP
ip route
default via 51.75.146.254 dev eno1 proto dhcp src 51.75.146.109 metric 100
51.75.146.0/24 dev eno1 proto kernel scope link src 51.75.146.109 metric 100
51.75.146.254 dev eno1 proto dhcp scope link src 51.75.146.109 metric 100
213.186.33.99 via 51.75.146.254 dev eno1 proto dhcp src 51.75.146.109 metric 100
Je modifie la conf :
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.254
set-name: eno1
>ping 51.75.146.254
ping: connect: Network is unreachable
ip route ne renvoi rien
> ip route
Quand je met l'IP publique du serveur en GW ça marche :
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.109
set-name: eno1
>ip route
default via 51.75.146.109 dev eno1 proto static
>PING google.fr (142.250.186.131) 56(84) bytes of data.
64 bytes from fra24s07-in-f3.1e100.net (142.250.186.131): icmp_seq=1 ttl=113 time=2.56 ms
J'ai juste des bases en réseaux et je reste perplexe sur ce comportement et me dis que je fais une connerie quelque part.
Debian netplan IPv4 static default gateway
Related questions
- Proxmox VM accès internet impossible
54868
19.11.2016 12:11
- Spam et IP bloquée
52226
12.12.2016 11:53
- il y a quelqu'un ?
51266
15.12.2025 17:01
- Mise en place de VM avec IP publique sur Proxmox 6 [RESOLU]
50320
30.04.2020 17:12
- SSD NVMe Soft Raid ou SSD SATA Hard Raid
49855
29.06.2021 23:29
- Port 25 bloqué pour spam à répétition
46973
28.02.2018 13:39
- Mise à jour PHP sur Release 3 ovh
46311
11.03.2017 17:43
- Identification carte réseau
45096
05.12.2025 10:09
- Connection smtp qui ne marche plus : connect error 10060
44662
12.04.2019 10:10
- Partition sur le disque de l'OS ESXI
44358
09.05.2017 14:33
Bonjour,
Il manque un bout (on-link) dans ton fichier, il devrait plutôt être :
[code]
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.254
on-link: true
set-name: eno1
[/code]
Cordialement, janus57
Merci @janus57. Mais cela ne résous pas le pb.
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.254
on-link: true
set-name: eno1
>netplan try --timeout 10
est ok
>netplan apply
> ping 51.75.146.254
> ping: connect: Network is unreachable
"ip route" ne renvoi rien
ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eno1: mtu 1500 qdisc mq state UP group default qlen 1000
link/ether a4:bf:01:41:83:a5 brd ff:ff:ff:ff:ff:ff
altname enp2s0
inet 51.75.146.109/32 scope global eno1
valid_lft forever preferred_lft forever
inet6 fe80::a6bf:1ff:fe41:83a5/64 scope link
valid_lft forever preferred_lft forever
3: eno2: mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether a4:bf:01:41:83:a6 brd ff:ff:ff:ff:ff:ff
altname enp3s0
Bonjour,
il y a un truc pas logique là, comment le try peut être OK si tu perd ta route vers la gateway ?
A ce stade tu devrait perdre la connexion et netplan fait un rollback.
Si tu lance le "try" en KVM/IPMI est-ce que tu perd la connexion SSH ?
Cordialement, janus57
Je fais tout en KVM.
> il y a un truc pas logique là, comment le try peut être OK si tu perd ta route vers la gateway ?
Et pourtant :
root@rescue:/etc/netplan# netplan try --timeout 10
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 1 seconds
Reverting.
avec :
root@rescue:/etc/netplan# cat 50-cloud-init.yaml
---
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
routes:
- to: default
via: 51.75.146.254
set-name: eno1
A ce moment là c'est toujours la conf d'origine qui joue :
root@rescue:/etc/netplan# ip route
default via 51.75.146.254 dev eno1 proto dhcp src 51.75.146.109 metric 100
51.75.146.0/24 dev eno1 proto kernel scope link src 51.75.146.109 metric 100
51.75.146.254 dev eno1 proto dhcp scope link src 51.75.146.109 metric 100
213.186.33.99 via 51.75.146.254 dev eno1 proto dhcp src 51.75.146.109 metric 100
Puis :
root@rescue:/etc/netplan# netplan apply
root@rescue:/etc/netplan#
root@rescue:/etc/netplan# ip route
root@rescue:/etc/netplan# ping 51.75.146.254
ping: connect: Network is unreachable
root@rescue:/etc/netplan#
Bonjour,
il faudrait une session KVM + SSH pour vérifier en live depuis internet.
Normalement pendant le try c'est là ou on fait les tests réseau puis seulement on applique si tout est OK.
De plus je vois que dans le dernier fichier posté le on-link à de nouveau disparu, il n'y aurait pas encore cloud-init de présent qui te joue des mauvais tours ?
**EDIT :**
Je vais tester avec mon KS1 car cela me semble bizarre..
Cordialement, janus57
Si tu veux (je veux pas t’embêter) envoi moi en MP ta clé RSA pub et je te met à dispo la machine.
Je vais lancer une fresh install (car j'ai désactivé IPV6 dessus).
J'ai le même phénomène avec un VPS.
Bonjour,
ça c'est d'autant plus bizarre que je l'avais testé, validé et documenté sur un VPS (Cf : https://community.ovhcloud.com/community/fr/rEsolu-sous-debian-12-passer-la-configuration-reseau-dhcp-a-static?id=community_question&sys_id=6a43d09ce596c6d02d4c0165b3e76632?u=janus57) et que je viens de le reproduire avec succès sur le même VPS réinstallé.
Cordialement, janus57
Ou j'ai lu plusieurs fois toutes tes interventions très utiles sur netplan.
Plus ça va plus je me dis que mes pb viennent du fait que je ne veuille pas de l'IPv6.
Tu serais bcp plus confort sur une vrai console SSH SOL que sur un KS (j'ai pas de VPS "moderne" et le KVM est quasi inutilisable)
Bonjour,
je viens de test premier coup => zéro problème
Je te fait un MP pour te montrer mes fichiers au complet.
Cordialement, janus57
ça marche... avec reboot et tout le toutim.
Énorme merci @janus57.
---
network:
version: 2
ethernets:
eno1:
accept-ra: false
addresses:
- 51.75.146.109/32
dhcp4: false
match:
macaddress: a4:bf:01:41:83:a5
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
routes:
- to: default
via: 51.75.146.254
on-link: true
set-name: eno1
Je réinstaller complètement avec mes commandes post config rzo car j'ai toujours pas compris où était mon erreur :
apt install -y yamllint openvswitch-switch
chmod 600 /etc/netplan/50-cloud-init.yaml
apt purge cloud-init && apt autoclean && apt autoremove && apt autopurge
echo "net.ipv6.conf.all.disable_ipv6 = 1" > /etc/sysctl.d/70-disable-ipv6.conf
sysctl -p -f /etc/sysctl.d/70-disable-ipv6.conf
Hello, j'arrive un peu tard mais il me semble que parfois j'ai carrément dû redémarrer `systemd-networkd.service` (et peut-être jouer avec `networkctl reconfigure `) car `netplan try` ne nettoyait pas tout.
Il faut savoir que netplan n'est qu'une fine surcouche de `systemd-networkd` et il crée des fichiers dans `/run/systemd/network/` qui sont interprétés par ce dernier.
Si jamais, https://superuser.com/a/1234599 voilà comment activer le debug du service.
Bah en même temps un 1er mai y-a que les indép (et @janus57) qui bossent hein :)
Merci beaucoup pour ton retour et ton suivi hautement apprécié. La piste est très intéressante car au final je n'ai toujours pas compris ce qui déconnait.