The first one is especially bad because it seems to suggest that, on Bionic, one can set an MTU by only matching on one of the "Predictable Network Interface Names". Which of course has never worked on Bionic, per this bug.
Only after clicking through various forum links does one come to this bug report. Nowhere does any of this appear in the ubuntu or netplan documentation. I mean, if it's been known for a year or more that many aspects of netplan don't work as-advertised on renamed devices, and by default almost all network devices get renamed these days, this seems like a major problem for the default network configuration tool, no?
Last, needing to match on MAC addresses to work around issues caused by "predictable interface names" is particularly perverse! Recall that one of the main rationales for such interface renaming (instead of eth0 etc) was that MAC addresses aren't necessarily static on embedded / virtualized systems: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
I just got bit by this one too.
This is frustrating since the top two (for me) Google hits for "ubuntu netplan mtu" both come from official Ubuntu sources, and both provide broken solutions: /blog.ubuntu. com/2017/ 12/01/ubuntu- bionic- netplan /blog.ubuntu. com/2017/ 07/05/quick- and-easy- network- configuration- with-netplan
https:/
https:/
The first one is especially bad because it seems to suggest that, on Bionic, one can set an MTU by only matching on one of the "Predictable Network Interface Names". Which of course has never worked on Bionic, per this bug.
Only after clicking through various forum links does one come to this bug report. Nowhere does any of this appear in the ubuntu or netplan documentation. I mean, if it's been known for a year or more that many aspects of netplan don't work as-advertised on renamed devices, and by default almost all network devices get renamed these days, this seems like a major problem for the default network configuration tool, no?
Last, needing to match on MAC addresses to work around issues caused by "predictable interface names" is particularly perverse! Recall that one of the main rationales for such interface renaming (instead of eth0 etc) was that MAC addresses aren't necessarily static on embedded / virtualized systems: /www.freedeskto p.org/wiki/ Software/ systemd/ PredictableNetw orkInterfaceNam es/
https:/