[PKG-Openstack-devel] [ovs-dev] Bug#771863: Bug#771863: Bug#771863: Service does not start or parse interfaces correctly

Tue Dec 30 15:39:17 UTC 2014

Il 30/12/2014 11:39, Fabio Fantoni ha scritto:
> Il 23/12/2014 16:27, Gurucharan Shetty ha scritto:
>>> I tried 2.3.0+git20140819-3 building it in wheezy with kernel 3.16 from
>>> backports but bridge of my test was still not working:
>>>> auto xenbr0
>>>> allow-ovs xenbr0
>>>> iface xenbr0 inet static
>>>>         address 192.168.1.90
>>>>          netmask 255.255.255.0
>>>>          network 192.168.1.0
>>>>          broadcast 192.168.1.255
>>>>          gateway 192.168.1.200
>>>>          ovs_type OVSBridge
>>>>          ovs_ports eth0
>>>>
>>>> auto eth0
>> You should not be using 'auto' above. eth0 is a port of an OVS bridge
>> and it should be configured after 'xenbr0' is configured.
>>
>>>> allow-xenbr0 eth0
>>>> iface eth0 inet manual
>>>>          ovs_bridge xenbr0
>>>>          ovs_type OVSPort
>>>>
>>>> auto xenbr1
>>>> allow-ovs xenbr1
>>>> iface xenbr1 inet static
>>>>         address 192.168.45.91
>>>>          netmask 255.255.255.0
>>>>          network 192.168.45.0
>>>>          broadcast 192.168.45.255
>>>>          ovs_type OVSBridge
>>>>          ovs_ports vlan100
>>>>
>>>> allow-xenbr1 vlan100
>>>> iface vlan100 inet manual
>>>>          ovs_bridge xenbr1
>>>>          ovs_type OVSIntPort
>>>>          ovs_options tag=100
>>>>          ovs_extra set interface ${IFACE} 
>>>> external-ids:iface-id=$(hostname
>>>> -s)
>> Without applying the below mentioned patch, does your problem go away
>> if you remove all the 'auto' for xenbr0 and xenbr1 also?
>
> Thanks for your reply.
> I removed all auto and now works also without backports other patches.
> Then ovs networks starts automatically on boot also without "auto", is 
> it correct?

I tried also other network type and bonding following 
openvswitch-switch.README.Debian and is not working:

allow-ovs xenbr0
iface xenbr0 inet static
      address 192.168.1.90
      netmask 255.255.255.0
      network 192.168.1.0
      broadcast 192.168.1.255
      gateway 192.168.1.200
      ovs_type OVSBridge
      ovs_ports bond0

allow-xenbr0 bond0
iface bond0 inet manual
#     pre-up ip link set dev eth0 up
#    pre-up ip link set dev eth1 up
      ovs_bridge xenbr0
      ovs_type OVSBond
      ovs_bonds eth0 eth1
      ovs_options bond_mode=balance-tcp lacp=active

allow-bond0 eth0
iface eth0 inet manual
         ovs_bridge bond0
         ovs_type OVSPort

allow-bond0 eth1
iface eth1 inet manual
         ovs_bridge bond0
         ovs_type OVSPort

I tried also pre-up in bond for the second test without result.
I did something wrong in configuration?

Thanks for any reply and sorry for my bad english.

>
>>>
>>> For have it working I had to do "service networking restart".
>>> I found probably final solution applying also this patch:
>>> http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=9a8b5cc1a3d941c0e33f3f5b5ac260a35a8130af 
>>>
>> The above patch adds the ability to configure OVS with 'auto'
>> configured and additionally has the following information:
>> """
>> Notes on dependencies:
>> ---------------------
>>
>> openvswitch-switch depends on $network, $named $remote_fs and $syslog 
>> to start.
>> This creates some startup dependency issues.
>>
>> * Since openvswitch utilities are placed in /usr and /usr can be mounted
>> through NFS, openvswitch has to start after it.  But if a user uses 
>> openvswitch
>> for all his networking needs and hence to mount NFS, there will be a 
>> deadlock.
>> So, if /usr is mounted through NFS and openvswitch is used for all 
>> networking,
>> the administrator should figure out a way to mount NFS before 
>> starting OVS.
>> One way to do this is in initramfs.
>>
>> * Since openvswitch starts after $network, $remote_fs and $syslog, 
>> any startup
>> script that depends on openvswitch but starts before it, needs to be 
>> changed
>> to depend on openvswitch-switch too.
>>
>> * Ideally, an admin should not add openvswitch bridges in the 'auto'
>> section of the 'interfaces' file.  This is because, when ifupdown starts
>> working on bridges listed in 'auto', openvswitch has not yet started.
>>
>> But, if the admin wants to go down this route and adds openvswitch 
>> bridges
>> in the 'auto' section, openvswitch-switch will forcefully be started 
>> when
>> ifupdown kicks in. In a case like this, the admin needs to make sure 
>> that /usr
>> has already been mounted and that a remote $syslog (if used) is ready to
>> receive openvswitch logs.
>> """
>>
>>
>>> Even if seems not good in some cases.
>> Does the above explanation give any hints on why it wouldn't work in 
>> some cases?
> Yes
>
>>
>>> I don't know if also Jessie have this problem but probably yes. If 
>>> yes I
>>> think this bug is only partially solves with 2.3.0+git20140819-3.
>>>
>>>
>>>
>>> I had also another start problem probably not related to this, after 
>>> some
>>> hours xenbr0 stopped to working.
>>> I not found any useful errors about in logs, only some strange 
>>> thing, in
>>> ifconfig xenbr0 was without the static ip, in syslog keep tried to 
>>> acquire
>>> configuration with dhcp failing (dhcp server present and working in 
>>> lan).
>>> After "service networking restart" was working again but I not 
>>> understand
>>> was happen and why :(
>>> Someone have any idea about?
>>>
>>>
>>>
>>> Thanks for any reply and sorry for my bad english.
>>> _______________________________________________
>>> dev mailing list
>>> dev at openvswitch.org
>>> http://openvswitch.org/mailman/listinfo/dev
>