lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway scheme

B

benitoll

Active Member
Feb 19, 2015
18
0
41
Las Palmas de Gran Canaria, Spain
www.nosoloservers.com
Hi,


I have a non vRack dedicated server with latest Proxmox 4.0 beta2, and I want to create at least one LXC container with some public IPs. The (mandatory?) gateway for bridged VM network configuration on (non vRack) OVH dedicated servers is [First three host IP's octets].254 (for example 188.165.1.1 would be 188.165.1.254), and 255.255.255.255 netmask. I am not very networking knowledgeable (yet) but after some investigation I found this output at (succesful) CT creation:


Code: 
[COLOR=#000000][FONT=tahoma]extracting archive '/var/lib/vz/template/cache/ubuntu-14.04-standard_14.04-1_amd64.tar.gz'[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]Total bytes read: 437422080 (418MiB, 147MiB/s)[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]Detected container architecture: amd64[/FONT][/COLOR]
[U][COLOR=#ff0000][FONT=tahoma]unable to parse ipv4 address/mask[/FONT][/COLOR][/U]
[COLOR=#000000][FONT=tahoma]TASK OK[/FONT][/COLOR]

and the recently created CT isn't able to start, this is the log (got it by manually starting the container with --logfile):


Code: 
      lxc-start 1442719037.698 ERROR    lxc_conf - conf.c:run_buffer:336 - Script exited with status 2
      lxc-start 1442719037.698 ERROR    lxc_conf - conf.c:lxc_setup:3827 - failed to run mount hooks for container '199'.
      lxc-start 1442719037.698 ERROR    lxc_start - start.c:do_start:702 - failed to setup the container
      lxc-start 1442719037.698 ERROR    lxc_sync - sync.c:__sync_wait:51 - invalid sequence number 1. expected 2
      lxc-start 1442719037.728 ERROR    lxc_start - start.c:__lxc_start:1172 - failed to spawn '199'
      lxc-start 1442719042.935 ERROR    lxc_start_ui - lxc_start.c:main:344 - The container failed to start.
      lxc-start 1442719042.935 ERROR    lxc_start_ui - lxc_start.c:main:346 - To get more details, run the container in foreground mode.
      lxc-start 1442719042.935 ERROR    lxc_start_ui - lxc_start.c:main:348 - Additional information can be obtained by setting the --logfile and --logpriority options.


/etc/pve/lxc/199.conf is properly created but /var/lib/lxc/199/config isn't at all, but it gets immediately created after deleting the network device from Proxmox GUI (no need for any action, just delete the device and "ls /var/lib/lxc/199/" show it's there).


Re-adding the network device from the GUI gets the "IP address" and "Gateway" fields empty just after clicking "Apply". Manually adding the "lxc.network.ipv4" and "lxc.network.ipv4.gateway" on /var/lib/lxc/199/config also gets them empty (and deleted from the /var/lib/lxc/199/config file) at CT start.


I think this should be a relatively very easy fix in the parser part, but please, if possible, show me a hacky workaround (even using another networking scheme - unless it's too complicated/undocumented for a beginner).



I'd greatly appreaciate some help just to get it working ASAP and after that I don't mind giving server access to devs for testing of potential permanent solutions for the problem (unless it requires a reboot or very high CPU/IO/RAM, I'm okay with whatever).
Thank you very much in advance.

PS: if it matters, I've got a /27 and several /32, but the ideal thing is to be able to use some of the addresses of the /27 for the main LXC container, and leave some others for another containers and VMs.
 
Last edited:
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

I'm so tired I accidentaly pressed enter while editing the title, it should be "LXC container 'unable to parse ipv4 address/mask' with OVH's mandatory bridged networking scheme" (if such a large title even fits xD).


I don't know if I left anything else unfinished/unpolished, hope not, but this incident tells me I've got to go to bed. Hupefully you kind people can help me (and note the bug to permanently fix it). Thanks again!!
 
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

Sorry, I o not understand why you do exacty, but "255.255.255.255" is no valid gateway address. Please can you post the CT configuration file?
 
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

I meant subnet mask not gateway T_T (gateway is hostip_first_3_octets.254 as I previously said). I will provide the config file but it's of no interest given the problem is the needed configuration isn't processed by the parser and written to the config file (and deleted if manually applied). The parser thinks the network configuration is wrong but it isn't. It also happened in original release of CentOS 7 (not anymore)

Code: 
lxc.arch = amd64lxc.include = /usr/share/lxc/config/ubuntu.common.conf
lxc.tty = 2
lxc.utsname = ubuntu.lxc.test
lxc.cgroup.memory.limit_in_bytes = 12884901888
lxc.cgroup.memory.memsw.limit_in_bytes = 13958643712
lxc.cgroup.cpu.cfs_period_us = 100000
lxc.cgroup.cpu.cfs_quota_us = 800000
lxc.cgroup.cpu.shares = 1024
lxc.rootfs = /raid0/subvol-199-disk-1
lxc.network.type = empty

Typo fixed in the original message. Thanks in advance.
 
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

benitoll said:
The parser thinks the network configuration is wrong but it isn't.
Click to expand...

What network configuration? - please can you post the container configuration including the network config (from /etc/pve/lxc/<ctid>.conf)?
 
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

And why do you use plain lxc instead of our configuration format?
 
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

dietmar said:
And why do you use plain lxc instead of our configuration format?
Click to expand...
Not really using "plain LXC" (I would temporarily if it's needed for the CT to have network until the bug is fixed), just I sent that config file and not the other. For being able to send you the proper one, with the desired networking configuration, I'll need to recreate the LXC (remember I can't add it after CT creation because the fields get instantly deleted).


Content of /etc/pve/lxc/199.conf:

Code: 
arch: amd64
cpulimit: 8
cpuunits: 1024
hostname: debian.lxc.test
memory: 12288
net0: name=eth0,[COLOR=#000080]hwaddr=[/COLOR][COLOR=#ff0000](FAKE)OVH_ISSUED_vMAC[/COLOR],bridge=vmbr0,[COLOR=#000080]ip=[/COLOR][COLOR=#ff0000]5.196.203.198/32[/COLOR],[COLOR=#000080]gw=[/COLOR][COLOR=#ff0000]149.202.65.254[/COLOR],firewall=1
ostype: debian
rootfs: ZFSpool:subvol-199-disk-1,size=40G
swap: 1024


CT creation log:

Code: 
[COLOR=#000000][FONT=tahoma]extracting archive '/var/lib/vz/template/cache/debian-8.0-standard_8.0-1_amd64.tar.gz'[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]Total bytes read: 533012480 (509MiB, 149MiB/s)[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]Detected container architecture: amd64[/FONT][/COLOR]
[COLOR=#ff0000][FONT=tahoma]unable to parse ipv4 address/mask[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]TASK OK
[/FONT][/COLOR]


/var/lib/lxc/199/config doesn't exist until I delete the networking device from the CT (it gets automatically and instantly created after that, sorry for repeating, just in case). Of course, without that config, the CT can't boot (says "TASK OK" but isn't really "OK").

Boot attemp basic GUI log:

Code: 
[COLOR=#000000][FONT=tahoma]lxc-start: lxc_start.c: main: 344 The container failed to start.[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]lxc-start: lxc_start.c: main: 346 To get more details, run the container in foreground mode.[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options.[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]TASK OK
[/FONT][/COLOR]



In this bridged networking scheme, the netmask I'm supposed to use is 255.255.255.255. Sorry if anything I'm being repetitive about is obvious.


Thanks!!
 
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

dietmar said:
This netmask is not considered valid (/30 is the smallest possible value). Also see

https://en.wikipedia.org/wiki/IPv4_subnetting_reference
Click to expand...


I know it's not considered valid, but it's 100% for sure the scheme used by OVH. A weird one? yes, but that is (unless one have a vRack enabled server with your own VLAN/s, that are few models). I am not an expert but I am pretty sure (AFAIK) it's not just the recommended scheme in OVH, but it's the mandatory only one possible.

Here some OVH documentation, explaining how to configure VMs network under a bridged scheme (it doesn't explain why it's like that, only how to do it) and 255.255.255.255 IS the netmask (and I've used OVH servers for virtualization for 4 years with that netmask on Proxmox KVM VMs): http://docs.ovh.ca/en/guides-network-bridging.html && http://help.ovh.co.uk/bridgeclient.


It is something related (my network knowledge is still too limited) to the additional "fail over" IPs not being in the same subnet/CIDR range at all to the main unmovable server IP (and/or the gateway being [3 first octets of host IP].254).

Another examples of parsers not letting use that scheme are first CentOS 7.0 release GUI installer (from .iso) on which you had to manually configure it from shell (now it's possible, it must be for a reason isn't it?), and FreeBSD where it still doesn't let you use that scheme from the GUI.

Hope I explained well enough, I'm about to go to sleep right now and if I cannot use the LXC container today, I will be forced to use a KVM VM or even bare metal until I can afford again to have a downtime. I'd accept any "hacky" temporary solution, hope you understand and my intuition tells me it has an easy fix (easy for anyone who knows what to modify and how xD).

Thanks.
 
Last edited:
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

benitoll said:
I'd accept any "hacky" temporary solution, hope you understand and my intuition tells me it has an easy fix (easy for anyone who knows what to modify and how xD).
Click to expand...

You can create a (static) network without assigning an IP configuration. You can then configure the network inside the container.
 
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

dietmar said:
You can create a (static) network without assigning an IP configuration. You can then configure the network inside the container.
Click to expand...

I feel dumb now, I've not tried yet but seems logic. You should consider allowing the parser to process OVH-like networking scheme, and (somehow) more than one non-consecutive IP/CIDR on a single vNIC.


Thanks again, even if you don't think so that answer will help a lot of people (and even more if you can do a permanent "fix" for OVH).

Regards.
 
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

Hi, the temporary solution is good enough (besides the problem I describe below), but please consider allowing the parser to not deny such networking scheme.


By the way, I'm not sure if I should open a new thread for this, but the temporary solution carries another problem: one can't ifdown/ifup alias IPs (eth0:0 for example). I have a problem with one IP not working (probably OVH's fault, sometimes happen when you move vMAC assigned IPs from one server to another), and I can't imagine how to fix it without rebooting (because the commands don't work and "service networking restart" either)


I've tried to configure the IPs both ways (neither work):


Code: 
auto lo eth0
iface lo inet loopback
iface eth0 inet static
        address MAIN_VM_IP
        netmask 255.255.255.255
        broadcast MAIN_VM_IP
        post-up route add FIRST_3_OCTECTS_OF_HOST_IP.254 dev eth0
        post-up route add default gw FIRST_3_OCTECTS_OF_HOST_IP.254
        pre-down route del FIRST_3_OCTECTS_OF_HOST_IP.254 dev eth0
        pre-down route del default gw FIRST_3_OCTECTS_OF_HOST_IP.254
        post-up /sbin/ifconfig eth0:0 SECONDARY_VM_IP netmask 255.255.255.255 broadcast SECONDARY_VM_IP
        post-down /sbin/ifconfig eth0:0 down
        post-up /sbin/ifconfig eth0:1 SECONDARY_VM_IP netmask 255.255.255.255 broadcast SECONDARY_VM_IP
        post-down /sbin/ifconfig eth0:1 down
...


and


Code: 
auto lo eth0 eth0:0 eth0:1 eth0:2 eth0:3 eth0:4 eth0:5 eth0:6 eth0:7 eth0:8 eth0:9 eth0:10 eth0:11 eth0:12 eth0:13
iface lo inet loopback
iface eth0 inet static
        address MAIN_VM_IP
        netmask 255.255.255.255
        broadcast MAIN_VM_IP
        post-up route add FIRST_3_OCTECTS_OF_HOST_IP.254 dev eth0
        post-up route add default gw FIRST_3_OCTECTS_OF_HOST_IP.254
        pre-down route del FIRST_3_OCTECTS_OF_HOST_IP.254 dev eth0
        pre-down route del default gw FIRST_3_OCTECTS_OF_HOST_IP.254
iface eth0:0 inet static
        address SECONDARY_VM_IP
        netmask 255.255.255.255
iface eth0:1 inet static
        address SECONDARY_VM_IP
        netmask 255.255.255.255
...




Both give this when trying to ifup/ifdown:


Code: 
root@hostname:~# ifup eth0:0
Ignoring unknown interface eth0:0=eth0:0.
root@hostname:~# ifdown eth0:0
ifdown: interface eth0:0 not configured
root@hostname:~# ifup eth0:1
Ignoring unknown interface eth0:1=eth0:1.
root@hostname:~# ifdown eth0:1
ifdown: interface eth0:1 not configured
root@hostname:~# [B]service networking restart[/B]
stop: Job failed while stopping
start: Job is already running: networking
 
Last edited:
Re: lxc CT "unable to parse ipv4 address/mask" with OVH's bridget networki gateway sc

benitoll said:
Hi, the temporary solution is good enough (besides the problem I describe below), but please consider allowing the parser to not deny such networking scheme.
Click to expand...

Network will not work that way, so IMHO it is better to raise an error in that case.
benitoll said:
By the way, I'm not sure if I should open a new thread for this, but the temporary solution carries another problem: one can't ifdown/ifup alias IPs (eth0:0 for example).
Click to expand...

Please create a new thread.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom