Why is Netplan/Networkd not bringing up a static ethernet interface?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







0















I have a machine running Ubuntu Server 18.04. The network is configured using Netplan, so I have this config in /etc/netplan/01-netcfg.yaml:



network:
version: 2
renderer: networkd
ethernets:
enp1s0f0:
optional: false
addresses:
- 10.0.0.1/24
wifis:
wlp2s0:
optional: true
dhcp4: yes
access-points:
[...]


enp1s0f0 is connected to a device that may or may not be on (at boot or any other time). I want to run a DHCP server on this interface.



The trouble is, when I boot there's a delay of a few minutes and I see this message:



A start job is running for Wait for Network to be Configured


Eventually it times out, the boot continues, but enp1s0f0 is never configured or brought up. ip link show enp1s0f0 gives:



2: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff


I have no idea what the significance of NO-CARRIER is, but in case it's relevant, here's the output of sudo lspci -v:



01:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM57766 Gigabit Ethernet PCIe (rev 01)
Subsystem: Broadcom Limited NetXtreme BCM57766 Gigabit Ethernet PCIe
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at a0400000 (64-bit, prefetchable) [size=64K]
Memory at a0410000 (64-bit, prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable+ Count=6 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Device Serial Number 00-00-10-dd-b1-ef-65-21
Capabilities: [150] Power Budgeting <?>
Capabilities: [160] Virtual Channel
Capabilities: [1b0] Latency Tolerance Reporting
Kernel driver in use: tg3
Kernel modules: tg3


Now if I turn the attached device on, sure enough enp1s0f0 comes up:



2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff


But it's of no use at this point — the DHCP server won't work, because it couldn't start with enp1s0f0 no up at boot time. I need enp1s0f0 up and configured during boot, which I thought was the whole point of a static IP configuration. Even stranger is that it always has an IPv6 address, even when it's down:



2: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff
inet6 fe80::12dd:b1ff:feef:6521/64 scope link
valid_lft forever preferred_lft forever


If I check Netplan's debug output, I see:



$ sudo netplan --debug apply
** (generate:1555): DEBUG: 20:39:27.253: Processing input file //etc/netplan/01-netcfg.yaml..
** (generate:1555): DEBUG: 20:39:27.254: starting new processing pass
** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: adding wifi AP 'Jeff Winger's Wireless Hairbrush'
** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: setting default backend to 1
** (generate:1555): DEBUG: 20:39:27.254: enp1s0f0: setting default backend to 1
** (generate:1555): DEBUG: 20:39:27.254: Generating output files..
** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: Creating wpa_supplicant configuration file run/netplan/wpa-wlp2s0.conf
** (generate:1555): DEBUG: 20:39:27.254: Creating wpa_supplicant service enablement link /run/systemd/system/multi-user.target.wants/netplan-wpa@wlp2s0.service
** (generate:1555): DEBUG: 20:39:27.254: NetworkManager: definition wlp2s0 is not for us (backend 1)
** (generate:1555): DEBUG: 20:39:27.254: NetworkManager: definition enp1s0f0 is not for us (backend 1)
DEBUG:netplan generated networkd configuration exists, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:replug enp1s0f0: unbinding 0000:01:00.0 from /sys/bus/pci/drivers/tg3
DEBUG:replug enp1s0f0: rebinding 0000:01:00.0 to /sys/bus/pci/drivers/tg3
DEBUG:device wlp2s0 operstate is up, not replugging
DEBUG:netplan triggering .link rules for wlp2s0
DEBUG:device lo operstate is unknown, not replugging
DEBUG:netplan triggering .link rules for lo


My configuration for isc-dhcp-server is to have /etc/default/isc-dhcp-server contain:



INTERFACESv4="enp1s0f0"


...and /etc/dhcp/dhcpd.conf contain (amongst other things):



subnet 10.0.0.0 netmask 255.255.255.0 {
...
}


In theory, this should serve DHCP over enp1s0f0. However, since enp1s0f0 is never brought up, the DHCP server fails to start:



No subnet declaration for enp1s0f0 (no IPv4 addresses).
** Ignoring requests on enp1s0f0. If this is not what
you want, please write a subnet declaration
in your dhcpd.conf file for the network segment
to which interface enp1s0f0 is attached. **


Not configured to listen on any interfaces!


This wasn't an issue under ifupdown (I have no idea why enp1s0f0 doesn't just come up during boot, whether or not anything is at the other end of the cable; I thought that was the whole point of having a static IP). Is it possible to get it working in Netplan? Or is it possible to have the DHCP server start when enp1s0f0 is up?










share|improve this question































    0















    I have a machine running Ubuntu Server 18.04. The network is configured using Netplan, so I have this config in /etc/netplan/01-netcfg.yaml:



    network:
    version: 2
    renderer: networkd
    ethernets:
    enp1s0f0:
    optional: false
    addresses:
    - 10.0.0.1/24
    wifis:
    wlp2s0:
    optional: true
    dhcp4: yes
    access-points:
    [...]


    enp1s0f0 is connected to a device that may or may not be on (at boot or any other time). I want to run a DHCP server on this interface.



    The trouble is, when I boot there's a delay of a few minutes and I see this message:



    A start job is running for Wait for Network to be Configured


    Eventually it times out, the boot continues, but enp1s0f0 is never configured or brought up. ip link show enp1s0f0 gives:



    2: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff


    I have no idea what the significance of NO-CARRIER is, but in case it's relevant, here's the output of sudo lspci -v:



    01:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM57766 Gigabit Ethernet PCIe (rev 01)
    Subsystem: Broadcom Limited NetXtreme BCM57766 Gigabit Ethernet PCIe
    Flags: bus master, fast devsel, latency 0, IRQ 16
    Memory at a0400000 (64-bit, prefetchable) [size=64K]
    Memory at a0410000 (64-bit, prefetchable) [size=64K]
    Capabilities: [48] Power Management version 3
    Capabilities: [50] Vital Product Data
    Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
    Capabilities: [a0] MSI-X: Enable+ Count=6 Masked-
    Capabilities: [ac] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [13c] Device Serial Number 00-00-10-dd-b1-ef-65-21
    Capabilities: [150] Power Budgeting <?>
    Capabilities: [160] Virtual Channel
    Capabilities: [1b0] Latency Tolerance Reporting
    Kernel driver in use: tg3
    Kernel modules: tg3


    Now if I turn the attached device on, sure enough enp1s0f0 comes up:



    2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff


    But it's of no use at this point — the DHCP server won't work, because it couldn't start with enp1s0f0 no up at boot time. I need enp1s0f0 up and configured during boot, which I thought was the whole point of a static IP configuration. Even stranger is that it always has an IPv6 address, even when it's down:



    2: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::12dd:b1ff:feef:6521/64 scope link
    valid_lft forever preferred_lft forever


    If I check Netplan's debug output, I see:



    $ sudo netplan --debug apply
    ** (generate:1555): DEBUG: 20:39:27.253: Processing input file //etc/netplan/01-netcfg.yaml..
    ** (generate:1555): DEBUG: 20:39:27.254: starting new processing pass
    ** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: adding wifi AP 'Jeff Winger's Wireless Hairbrush'
    ** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: setting default backend to 1
    ** (generate:1555): DEBUG: 20:39:27.254: enp1s0f0: setting default backend to 1
    ** (generate:1555): DEBUG: 20:39:27.254: Generating output files..
    ** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: Creating wpa_supplicant configuration file run/netplan/wpa-wlp2s0.conf
    ** (generate:1555): DEBUG: 20:39:27.254: Creating wpa_supplicant service enablement link /run/systemd/system/multi-user.target.wants/netplan-wpa@wlp2s0.service
    ** (generate:1555): DEBUG: 20:39:27.254: NetworkManager: definition wlp2s0 is not for us (backend 1)
    ** (generate:1555): DEBUG: 20:39:27.254: NetworkManager: definition enp1s0f0 is not for us (backend 1)
    DEBUG:netplan generated networkd configuration exists, restarting networkd
    DEBUG:no netplan generated NM configuration exists
    DEBUG:replug enp1s0f0: unbinding 0000:01:00.0 from /sys/bus/pci/drivers/tg3
    DEBUG:replug enp1s0f0: rebinding 0000:01:00.0 to /sys/bus/pci/drivers/tg3
    DEBUG:device wlp2s0 operstate is up, not replugging
    DEBUG:netplan triggering .link rules for wlp2s0
    DEBUG:device lo operstate is unknown, not replugging
    DEBUG:netplan triggering .link rules for lo


    My configuration for isc-dhcp-server is to have /etc/default/isc-dhcp-server contain:



    INTERFACESv4="enp1s0f0"


    ...and /etc/dhcp/dhcpd.conf contain (amongst other things):



    subnet 10.0.0.0 netmask 255.255.255.0 {
    ...
    }


    In theory, this should serve DHCP over enp1s0f0. However, since enp1s0f0 is never brought up, the DHCP server fails to start:



    No subnet declaration for enp1s0f0 (no IPv4 addresses).
    ** Ignoring requests on enp1s0f0. If this is not what
    you want, please write a subnet declaration
    in your dhcpd.conf file for the network segment
    to which interface enp1s0f0 is attached. **


    Not configured to listen on any interfaces!


    This wasn't an issue under ifupdown (I have no idea why enp1s0f0 doesn't just come up during boot, whether or not anything is at the other end of the cable; I thought that was the whole point of having a static IP). Is it possible to get it working in Netplan? Or is it possible to have the DHCP server start when enp1s0f0 is up?










    share|improve this question



























      0












      0








      0








      I have a machine running Ubuntu Server 18.04. The network is configured using Netplan, so I have this config in /etc/netplan/01-netcfg.yaml:



      network:
      version: 2
      renderer: networkd
      ethernets:
      enp1s0f0:
      optional: false
      addresses:
      - 10.0.0.1/24
      wifis:
      wlp2s0:
      optional: true
      dhcp4: yes
      access-points:
      [...]


      enp1s0f0 is connected to a device that may or may not be on (at boot or any other time). I want to run a DHCP server on this interface.



      The trouble is, when I boot there's a delay of a few minutes and I see this message:



      A start job is running for Wait for Network to be Configured


      Eventually it times out, the boot continues, but enp1s0f0 is never configured or brought up. ip link show enp1s0f0 gives:



      2: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
      link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff


      I have no idea what the significance of NO-CARRIER is, but in case it's relevant, here's the output of sudo lspci -v:



      01:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM57766 Gigabit Ethernet PCIe (rev 01)
      Subsystem: Broadcom Limited NetXtreme BCM57766 Gigabit Ethernet PCIe
      Flags: bus master, fast devsel, latency 0, IRQ 16
      Memory at a0400000 (64-bit, prefetchable) [size=64K]
      Memory at a0410000 (64-bit, prefetchable) [size=64K]
      Capabilities: [48] Power Management version 3
      Capabilities: [50] Vital Product Data
      Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
      Capabilities: [a0] MSI-X: Enable+ Count=6 Masked-
      Capabilities: [ac] Express Endpoint, MSI 00
      Capabilities: [100] Advanced Error Reporting
      Capabilities: [13c] Device Serial Number 00-00-10-dd-b1-ef-65-21
      Capabilities: [150] Power Budgeting <?>
      Capabilities: [160] Virtual Channel
      Capabilities: [1b0] Latency Tolerance Reporting
      Kernel driver in use: tg3
      Kernel modules: tg3


      Now if I turn the attached device on, sure enough enp1s0f0 comes up:



      2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
      link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff


      But it's of no use at this point — the DHCP server won't work, because it couldn't start with enp1s0f0 no up at boot time. I need enp1s0f0 up and configured during boot, which I thought was the whole point of a static IP configuration. Even stranger is that it always has an IPv6 address, even when it's down:



      2: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
      link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::12dd:b1ff:feef:6521/64 scope link
      valid_lft forever preferred_lft forever


      If I check Netplan's debug output, I see:



      $ sudo netplan --debug apply
      ** (generate:1555): DEBUG: 20:39:27.253: Processing input file //etc/netplan/01-netcfg.yaml..
      ** (generate:1555): DEBUG: 20:39:27.254: starting new processing pass
      ** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: adding wifi AP 'Jeff Winger's Wireless Hairbrush'
      ** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: setting default backend to 1
      ** (generate:1555): DEBUG: 20:39:27.254: enp1s0f0: setting default backend to 1
      ** (generate:1555): DEBUG: 20:39:27.254: Generating output files..
      ** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: Creating wpa_supplicant configuration file run/netplan/wpa-wlp2s0.conf
      ** (generate:1555): DEBUG: 20:39:27.254: Creating wpa_supplicant service enablement link /run/systemd/system/multi-user.target.wants/netplan-wpa@wlp2s0.service
      ** (generate:1555): DEBUG: 20:39:27.254: NetworkManager: definition wlp2s0 is not for us (backend 1)
      ** (generate:1555): DEBUG: 20:39:27.254: NetworkManager: definition enp1s0f0 is not for us (backend 1)
      DEBUG:netplan generated networkd configuration exists, restarting networkd
      DEBUG:no netplan generated NM configuration exists
      DEBUG:replug enp1s0f0: unbinding 0000:01:00.0 from /sys/bus/pci/drivers/tg3
      DEBUG:replug enp1s0f0: rebinding 0000:01:00.0 to /sys/bus/pci/drivers/tg3
      DEBUG:device wlp2s0 operstate is up, not replugging
      DEBUG:netplan triggering .link rules for wlp2s0
      DEBUG:device lo operstate is unknown, not replugging
      DEBUG:netplan triggering .link rules for lo


      My configuration for isc-dhcp-server is to have /etc/default/isc-dhcp-server contain:



      INTERFACESv4="enp1s0f0"


      ...and /etc/dhcp/dhcpd.conf contain (amongst other things):



      subnet 10.0.0.0 netmask 255.255.255.0 {
      ...
      }


      In theory, this should serve DHCP over enp1s0f0. However, since enp1s0f0 is never brought up, the DHCP server fails to start:



      No subnet declaration for enp1s0f0 (no IPv4 addresses).
      ** Ignoring requests on enp1s0f0. If this is not what
      you want, please write a subnet declaration
      in your dhcpd.conf file for the network segment
      to which interface enp1s0f0 is attached. **


      Not configured to listen on any interfaces!


      This wasn't an issue under ifupdown (I have no idea why enp1s0f0 doesn't just come up during boot, whether or not anything is at the other end of the cable; I thought that was the whole point of having a static IP). Is it possible to get it working in Netplan? Or is it possible to have the DHCP server start when enp1s0f0 is up?










      share|improve this question
















      I have a machine running Ubuntu Server 18.04. The network is configured using Netplan, so I have this config in /etc/netplan/01-netcfg.yaml:



      network:
      version: 2
      renderer: networkd
      ethernets:
      enp1s0f0:
      optional: false
      addresses:
      - 10.0.0.1/24
      wifis:
      wlp2s0:
      optional: true
      dhcp4: yes
      access-points:
      [...]


      enp1s0f0 is connected to a device that may or may not be on (at boot or any other time). I want to run a DHCP server on this interface.



      The trouble is, when I boot there's a delay of a few minutes and I see this message:



      A start job is running for Wait for Network to be Configured


      Eventually it times out, the boot continues, but enp1s0f0 is never configured or brought up. ip link show enp1s0f0 gives:



      2: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
      link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff


      I have no idea what the significance of NO-CARRIER is, but in case it's relevant, here's the output of sudo lspci -v:



      01:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM57766 Gigabit Ethernet PCIe (rev 01)
      Subsystem: Broadcom Limited NetXtreme BCM57766 Gigabit Ethernet PCIe
      Flags: bus master, fast devsel, latency 0, IRQ 16
      Memory at a0400000 (64-bit, prefetchable) [size=64K]
      Memory at a0410000 (64-bit, prefetchable) [size=64K]
      Capabilities: [48] Power Management version 3
      Capabilities: [50] Vital Product Data
      Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
      Capabilities: [a0] MSI-X: Enable+ Count=6 Masked-
      Capabilities: [ac] Express Endpoint, MSI 00
      Capabilities: [100] Advanced Error Reporting
      Capabilities: [13c] Device Serial Number 00-00-10-dd-b1-ef-65-21
      Capabilities: [150] Power Budgeting <?>
      Capabilities: [160] Virtual Channel
      Capabilities: [1b0] Latency Tolerance Reporting
      Kernel driver in use: tg3
      Kernel modules: tg3


      Now if I turn the attached device on, sure enough enp1s0f0 comes up:



      2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
      link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff


      But it's of no use at this point — the DHCP server won't work, because it couldn't start with enp1s0f0 no up at boot time. I need enp1s0f0 up and configured during boot, which I thought was the whole point of a static IP configuration. Even stranger is that it always has an IPv6 address, even when it's down:



      2: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
      link/ether 10:dd:b1:ef:65:21 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::12dd:b1ff:feef:6521/64 scope link
      valid_lft forever preferred_lft forever


      If I check Netplan's debug output, I see:



      $ sudo netplan --debug apply
      ** (generate:1555): DEBUG: 20:39:27.253: Processing input file //etc/netplan/01-netcfg.yaml..
      ** (generate:1555): DEBUG: 20:39:27.254: starting new processing pass
      ** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: adding wifi AP 'Jeff Winger's Wireless Hairbrush'
      ** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: setting default backend to 1
      ** (generate:1555): DEBUG: 20:39:27.254: enp1s0f0: setting default backend to 1
      ** (generate:1555): DEBUG: 20:39:27.254: Generating output files..
      ** (generate:1555): DEBUG: 20:39:27.254: wlp2s0: Creating wpa_supplicant configuration file run/netplan/wpa-wlp2s0.conf
      ** (generate:1555): DEBUG: 20:39:27.254: Creating wpa_supplicant service enablement link /run/systemd/system/multi-user.target.wants/netplan-wpa@wlp2s0.service
      ** (generate:1555): DEBUG: 20:39:27.254: NetworkManager: definition wlp2s0 is not for us (backend 1)
      ** (generate:1555): DEBUG: 20:39:27.254: NetworkManager: definition enp1s0f0 is not for us (backend 1)
      DEBUG:netplan generated networkd configuration exists, restarting networkd
      DEBUG:no netplan generated NM configuration exists
      DEBUG:replug enp1s0f0: unbinding 0000:01:00.0 from /sys/bus/pci/drivers/tg3
      DEBUG:replug enp1s0f0: rebinding 0000:01:00.0 to /sys/bus/pci/drivers/tg3
      DEBUG:device wlp2s0 operstate is up, not replugging
      DEBUG:netplan triggering .link rules for wlp2s0
      DEBUG:device lo operstate is unknown, not replugging
      DEBUG:netplan triggering .link rules for lo


      My configuration for isc-dhcp-server is to have /etc/default/isc-dhcp-server contain:



      INTERFACESv4="enp1s0f0"


      ...and /etc/dhcp/dhcpd.conf contain (amongst other things):



      subnet 10.0.0.0 netmask 255.255.255.0 {
      ...
      }


      In theory, this should serve DHCP over enp1s0f0. However, since enp1s0f0 is never brought up, the DHCP server fails to start:



      No subnet declaration for enp1s0f0 (no IPv4 addresses).
      ** Ignoring requests on enp1s0f0. If this is not what
      you want, please write a subnet declaration
      in your dhcpd.conf file for the network segment
      to which interface enp1s0f0 is attached. **


      Not configured to listen on any interfaces!


      This wasn't an issue under ifupdown (I have no idea why enp1s0f0 doesn't just come up during boot, whether or not anything is at the other end of the cable; I thought that was the whole point of having a static IP). Is it possible to get it working in Netplan? Or is it possible to have the DHCP server start when enp1s0f0 is up?







      server static-ip netplan dhcpd






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jun 17 '18 at 7:07







      detly

















      asked Jun 14 '18 at 5:45









      detlydetly

      1,44842745




      1,44842745






















          2 Answers
          2






          active

          oldest

          votes


















          2














          It looks like you're hitting the bug that will be solved by https://github.com/CanonicalLtd/netplan/pull/34 - currently devices will only be configured if they have a carrier, but that requirement is going away.



          In the mean time, you can probably fix this by configuring the device with systemd-networkd directly. Remove the enp1s0f0 stanza from the netplan config and add something like this (untested) systemd config in /etc/systemd/network/10-enp1s0f0.network:



          [Match]
          Name=enp1s0f0

          [Link]
          RequiredForOnline=no

          [Network]
          ConfigureWithoutCarrier=true
          Address=10.0.0.1/24


          The key bit is the ConfigureWithoutCarrier which I have pulled directly from the pull request.



          (You can see what netplan generates and go from there - the file will be in /run/systemd/network.)



          Alternatively, you can make use of the fact that netplan and ifupdown can coexist, apt install ifupdown and configure enp1s0f0 with ifupdown.






          share|improve this answer
























          • Good find! I searched these issues but just didn't have the right terms. I can't wait to see the back of ifupdown, so I'll try this workaround and subscribe to the bug. I'll let you know in a few hours.

            – detly
            Jun 19 '18 at 23:10











          • IT WORKS. Interestingly, it's still in the DOWN state (I never knew for sure whether that was the issue or not), but the address is configured and that means the DHCP server starts. Excellent.

            – detly
            Jun 20 '18 at 10:32











          • FYI I copied Netplan's rendered config from /run/systemd/network/10-netplan-enp1s0f0.network and didn't add the RequiredForOnline=no; THEN I removed the enp1s0f0 stanza and reapplied the Netplan config.

            – detly
            Jun 20 '18 at 10:34



















          1














          It looks like Netplan has a smart system of figuring out when the iface has a link or not and assign addresses only when the link is up, automatically.



          When that interface has no link (carrier signal), it remains unconfigured, however, if I turn on the other device in the other end of the cable, the interface automatically brings itself up with IP address and everything it needs.



          For DHCP, a solution would be not to bind it to a specific interface...






          share|improve this answer
























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "89"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1046420%2fwhy-is-netplan-networkd-not-bringing-up-a-static-ethernet-interface%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2














            It looks like you're hitting the bug that will be solved by https://github.com/CanonicalLtd/netplan/pull/34 - currently devices will only be configured if they have a carrier, but that requirement is going away.



            In the mean time, you can probably fix this by configuring the device with systemd-networkd directly. Remove the enp1s0f0 stanza from the netplan config and add something like this (untested) systemd config in /etc/systemd/network/10-enp1s0f0.network:



            [Match]
            Name=enp1s0f0

            [Link]
            RequiredForOnline=no

            [Network]
            ConfigureWithoutCarrier=true
            Address=10.0.0.1/24


            The key bit is the ConfigureWithoutCarrier which I have pulled directly from the pull request.



            (You can see what netplan generates and go from there - the file will be in /run/systemd/network.)



            Alternatively, you can make use of the fact that netplan and ifupdown can coexist, apt install ifupdown and configure enp1s0f0 with ifupdown.






            share|improve this answer
























            • Good find! I searched these issues but just didn't have the right terms. I can't wait to see the back of ifupdown, so I'll try this workaround and subscribe to the bug. I'll let you know in a few hours.

              – detly
              Jun 19 '18 at 23:10











            • IT WORKS. Interestingly, it's still in the DOWN state (I never knew for sure whether that was the issue or not), but the address is configured and that means the DHCP server starts. Excellent.

              – detly
              Jun 20 '18 at 10:32











            • FYI I copied Netplan's rendered config from /run/systemd/network/10-netplan-enp1s0f0.network and didn't add the RequiredForOnline=no; THEN I removed the enp1s0f0 stanza and reapplied the Netplan config.

              – detly
              Jun 20 '18 at 10:34
















            2














            It looks like you're hitting the bug that will be solved by https://github.com/CanonicalLtd/netplan/pull/34 - currently devices will only be configured if they have a carrier, but that requirement is going away.



            In the mean time, you can probably fix this by configuring the device with systemd-networkd directly. Remove the enp1s0f0 stanza from the netplan config and add something like this (untested) systemd config in /etc/systemd/network/10-enp1s0f0.network:



            [Match]
            Name=enp1s0f0

            [Link]
            RequiredForOnline=no

            [Network]
            ConfigureWithoutCarrier=true
            Address=10.0.0.1/24


            The key bit is the ConfigureWithoutCarrier which I have pulled directly from the pull request.



            (You can see what netplan generates and go from there - the file will be in /run/systemd/network.)



            Alternatively, you can make use of the fact that netplan and ifupdown can coexist, apt install ifupdown and configure enp1s0f0 with ifupdown.






            share|improve this answer
























            • Good find! I searched these issues but just didn't have the right terms. I can't wait to see the back of ifupdown, so I'll try this workaround and subscribe to the bug. I'll let you know in a few hours.

              – detly
              Jun 19 '18 at 23:10











            • IT WORKS. Interestingly, it's still in the DOWN state (I never knew for sure whether that was the issue or not), but the address is configured and that means the DHCP server starts. Excellent.

              – detly
              Jun 20 '18 at 10:32











            • FYI I copied Netplan's rendered config from /run/systemd/network/10-netplan-enp1s0f0.network and didn't add the RequiredForOnline=no; THEN I removed the enp1s0f0 stanza and reapplied the Netplan config.

              – detly
              Jun 20 '18 at 10:34














            2












            2








            2







            It looks like you're hitting the bug that will be solved by https://github.com/CanonicalLtd/netplan/pull/34 - currently devices will only be configured if they have a carrier, but that requirement is going away.



            In the mean time, you can probably fix this by configuring the device with systemd-networkd directly. Remove the enp1s0f0 stanza from the netplan config and add something like this (untested) systemd config in /etc/systemd/network/10-enp1s0f0.network:



            [Match]
            Name=enp1s0f0

            [Link]
            RequiredForOnline=no

            [Network]
            ConfigureWithoutCarrier=true
            Address=10.0.0.1/24


            The key bit is the ConfigureWithoutCarrier which I have pulled directly from the pull request.



            (You can see what netplan generates and go from there - the file will be in /run/systemd/network.)



            Alternatively, you can make use of the fact that netplan and ifupdown can coexist, apt install ifupdown and configure enp1s0f0 with ifupdown.






            share|improve this answer













            It looks like you're hitting the bug that will be solved by https://github.com/CanonicalLtd/netplan/pull/34 - currently devices will only be configured if they have a carrier, but that requirement is going away.



            In the mean time, you can probably fix this by configuring the device with systemd-networkd directly. Remove the enp1s0f0 stanza from the netplan config and add something like this (untested) systemd config in /etc/systemd/network/10-enp1s0f0.network:



            [Match]
            Name=enp1s0f0

            [Link]
            RequiredForOnline=no

            [Network]
            ConfigureWithoutCarrier=true
            Address=10.0.0.1/24


            The key bit is the ConfigureWithoutCarrier which I have pulled directly from the pull request.



            (You can see what netplan generates and go from there - the file will be in /run/systemd/network.)



            Alternatively, you can make use of the fact that netplan and ifupdown can coexist, apt install ifupdown and configure enp1s0f0 with ifupdown.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jun 19 '18 at 23:07









            djadja

            2081211




            2081211













            • Good find! I searched these issues but just didn't have the right terms. I can't wait to see the back of ifupdown, so I'll try this workaround and subscribe to the bug. I'll let you know in a few hours.

              – detly
              Jun 19 '18 at 23:10











            • IT WORKS. Interestingly, it's still in the DOWN state (I never knew for sure whether that was the issue or not), but the address is configured and that means the DHCP server starts. Excellent.

              – detly
              Jun 20 '18 at 10:32











            • FYI I copied Netplan's rendered config from /run/systemd/network/10-netplan-enp1s0f0.network and didn't add the RequiredForOnline=no; THEN I removed the enp1s0f0 stanza and reapplied the Netplan config.

              – detly
              Jun 20 '18 at 10:34



















            • Good find! I searched these issues but just didn't have the right terms. I can't wait to see the back of ifupdown, so I'll try this workaround and subscribe to the bug. I'll let you know in a few hours.

              – detly
              Jun 19 '18 at 23:10











            • IT WORKS. Interestingly, it's still in the DOWN state (I never knew for sure whether that was the issue or not), but the address is configured and that means the DHCP server starts. Excellent.

              – detly
              Jun 20 '18 at 10:32











            • FYI I copied Netplan's rendered config from /run/systemd/network/10-netplan-enp1s0f0.network and didn't add the RequiredForOnline=no; THEN I removed the enp1s0f0 stanza and reapplied the Netplan config.

              – detly
              Jun 20 '18 at 10:34

















            Good find! I searched these issues but just didn't have the right terms. I can't wait to see the back of ifupdown, so I'll try this workaround and subscribe to the bug. I'll let you know in a few hours.

            – detly
            Jun 19 '18 at 23:10





            Good find! I searched these issues but just didn't have the right terms. I can't wait to see the back of ifupdown, so I'll try this workaround and subscribe to the bug. I'll let you know in a few hours.

            – detly
            Jun 19 '18 at 23:10













            IT WORKS. Interestingly, it's still in the DOWN state (I never knew for sure whether that was the issue or not), but the address is configured and that means the DHCP server starts. Excellent.

            – detly
            Jun 20 '18 at 10:32





            IT WORKS. Interestingly, it's still in the DOWN state (I never knew for sure whether that was the issue or not), but the address is configured and that means the DHCP server starts. Excellent.

            – detly
            Jun 20 '18 at 10:32













            FYI I copied Netplan's rendered config from /run/systemd/network/10-netplan-enp1s0f0.network and didn't add the RequiredForOnline=no; THEN I removed the enp1s0f0 stanza and reapplied the Netplan config.

            – detly
            Jun 20 '18 at 10:34





            FYI I copied Netplan's rendered config from /run/systemd/network/10-netplan-enp1s0f0.network and didn't add the RequiredForOnline=no; THEN I removed the enp1s0f0 stanza and reapplied the Netplan config.

            – detly
            Jun 20 '18 at 10:34













            1














            It looks like Netplan has a smart system of figuring out when the iface has a link or not and assign addresses only when the link is up, automatically.



            When that interface has no link (carrier signal), it remains unconfigured, however, if I turn on the other device in the other end of the cable, the interface automatically brings itself up with IP address and everything it needs.



            For DHCP, a solution would be not to bind it to a specific interface...






            share|improve this answer




























              1














              It looks like Netplan has a smart system of figuring out when the iface has a link or not and assign addresses only when the link is up, automatically.



              When that interface has no link (carrier signal), it remains unconfigured, however, if I turn on the other device in the other end of the cable, the interface automatically brings itself up with IP address and everything it needs.



              For DHCP, a solution would be not to bind it to a specific interface...






              share|improve this answer


























                1












                1








                1







                It looks like Netplan has a smart system of figuring out when the iface has a link or not and assign addresses only when the link is up, automatically.



                When that interface has no link (carrier signal), it remains unconfigured, however, if I turn on the other device in the other end of the cable, the interface automatically brings itself up with IP address and everything it needs.



                For DHCP, a solution would be not to bind it to a specific interface...






                share|improve this answer













                It looks like Netplan has a smart system of figuring out when the iface has a link or not and assign addresses only when the link is up, automatically.



                When that interface has no link (carrier signal), it remains unconfigured, however, if I turn on the other device in the other end of the cable, the interface automatically brings itself up with IP address and everything it needs.



                For DHCP, a solution would be not to bind it to a specific interface...







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Aug 19 '18 at 21:31









                AdamAdam

                111




                111






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Ask Ubuntu!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1046420%2fwhy-is-netplan-networkd-not-bringing-up-a-static-ethernet-interface%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Human spaceflight

                    Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

                    張江高科駅