> On 4 Mar 2016, at 15:03, Thomas Haller <[email protected]> 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 <[email protected]> >>>> 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? >>>>> >>>>> tia >>>> Hi, >>>> >>>> >>>> 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, >>>> Thomas >> >> Hi 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/64 >> >> >> So 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. > > > Thomas
Thanks, 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. _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
