GNOME.org
 

Re: Is this the designed behaviour for NetworkManager



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?

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.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]