On Fri, 2016-03-04 at 15:49 +0000, Tim Coote wrote:
On 4 Mar 2016, at 15:03, Thomas Haller <thaller redhat com> wrote: On Fri, 2016-03-04 at 15:57 +0100, Thomas Haller wrote:On Fri, 2016-03-04 at 11:15 +0000, Tim Coote wrote:On 4 Mar 2016, at 10:40, Thomas Haller <thaller redhat com> wrote: On Fri, 2016-03-04 at 10:19 +0000, Tim Coote wrote:Hullo I’m starting to migrate my fedora stock to NetworkManager. In one particular test scenario, I tried to create a direct copy of the final machine configuration using NM and the old "systemctl start network” approach. The VMs are temporally separated (ie I spin up the old one save interrogation results about configuration; kill it and repeat with the new one). The only differences between the two machines should be the hostnames (so that the puppet configuration knows them as different machines) and the mac addresses. One inconsistency that I’ve found is that the NetworkManager cannot seem to spin up a tunnel unless the ipv4 addresses differ between the VMs. For the NM controlled VM, pulling apart the actual command run, I see: [code] nmcli con up uuid 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 <response> Error: Connection activation failed: No suitable device found for this connection. [/code] where the uuid represents the sit1 device. However, on the same VM (either directly invoked or by turning off NM and running ifup sit1): [code] /etc/sysconfig/network-scripts/ifup-sit sit1 [/code] spins up the tunnel. If I put the ‘copy’ VM on different IP address(es). NM seems happy to spin up the tunnel. Note that in both cases there are no conflicting computers/ip addresses on the network at the same time. Am I (probabably) seeing the intended behaviour for NM - in which case I need to modify my testing approach - or do I need to dig further to confirm a bug? tiaHi, which version of NetworkManager? what gives nmcli connection show 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 and how does the corresponding ifcfg-file look? cat /etc/sysconfig/network-scripts/ifcfg-* Thanks, ThomasHi Tim, Side note: usually it's better to answer with "reply-all", because then the mailing list might help you.Sorry. I wasn’t intending to get into debugging my setup, more trying to understand what the design should do. in any case: NetworkManager-1.0.6-6.fc23.x86_64 (stock f23)Note that this is not the most recent version on f23. Ithould be 1.0.10.the nmcli connection … was gleaned from running sh -x usr/sbin/ifup sit1. /usr/sbin/ifup comes from initscripts-9.64- 1.fc23.x86_64 nb. these are the versions of the files that work. To break the configuration I change the IP addresses from 172.17.1.9 to 172.17.1.10 and from 192.168.31.61 to 192.168.31.60 throughout. /etc/sysconfig/network-scripts/ifcfg-eth0 # Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express DEVICE=eth0 # temp static to avoid dhcp allcotion pluto as default router BOOTPROTO=none IPADDR=172.17.1.9 NETMASK=255.255.0.0 #HWADDR=00:15:58:09:b2:ec #needs to override dhcp, dhcp still used to ensure ip address not lost - fixme!! GATEWAY=192.168.31.100 ONBOOT=yes NM_CONTROLLED=no TYPE=Ethernet USERCTL=no # not using 6to4, but a dedicated tunnel. seems to work with this in, but generates warnings IPV6TO4INIT=yes IPV6INIT=yes IPV6ADDR_SECONDARIES="2001:470:zzzz::1/64" # unclear on value/necessity. I think it's for varying tunnels, so probably not essential IPV6_CONTROL_RADVD=yes PREFIX=16 /etc/sysconfig/network-scripts/ifcfg-eth0:1 # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. GATEWAY=192.168.31.100 DNS1=172.17.31.77 DEVICE=eth0:1 BOOTPROTO=none NETMASK=255.255.255.0 TYPE=Ethernet IPADDR=192.168.31.61 IPV6INIT=yes USERCTL=no ONPARENT=yes NM_CONTROLLED=no PREFIX=24 /etc/sysconfig/network-scripts/ifcfg-lo DEVICE=lo IPADDR=127.0.0.1 NETMASK=255.0.0.0 NETWORK=127.0.0.0 # If you're having problems with gated making 127.0.0.0/8 a martian, # you can change this to something else (255.255.255.255, for example) BROADCAST=127.255.255.255 ONBOOT=yes NAME=loopback /etc/sysconfig/network-scripts/ifcfg-sit1 DEVICE=sit1 BOOTPROTO=none ONBOOT=yes IPV6INIT=yes IPV6TUNNELIPV4=aaa.bbb.ccc.dddd IPV6TUNNELIPV4LOCAL=172.17.1.9 IPV6ADDR=2001:470:xxxx:yyyy::2/64So for me to understand: you used to call `ifup sit1` with initscripts alone, and it worked. Since enabling NetworkManager, `ifup sit1` ends up calling `nmcli connection up uuid 4a341ad1-3e31-7ee8-82ee-2019bf995ad8`, which now fails? When using initscripts with NetworkManager enabled, initscripts/ifup ask NetworkManager whether NM wants to handle a certain ifcfg file. If NM says yes, a ifup call results in `nmcli connection up`. Can you show what NM thinks how 4a341ad1 looks like? $ nmcli connection show 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 NetworkManager 1.0 and earlier don't support creation of sit tunnels. Only 1.2 does. NM should say that it doesn't know how to handle "/etc/sysconfig/network-scripts/ifcfg-sit1" and leave it to initscripts to up the sit connection.NM thinks that your sit1 file is an "ethernet", not a sit-tunnel. You have to put NM_CONTROLLED=no there. ThomasThanks, Thomas. That solved it. And it looks to me like my initial tests were wrong as I could not reproduce my initial success model. Looks like I’m hardly using NM at all.
Cool. addendum: even better then "NM_CONTROLLED=no" is "TYPE=sit". Then NetworkManager knows the type at hand and ignores it properly. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part