[technique] lxc.network.type = phys

Mer 1 Oct 11:58:57 CEST 2014

Les logs LXC en DEBUG ne donnent aucune ERROR, juste en boucle :

*lxc-start 1412157298.238 DEBUG    lxc_utmp - got inotify event 2 for
utmplxc-start 1412157298.238 DEBUG    lxc_utmp - utmp handler - run level
is N/3lxc-start 1412157298.238 DEBUG    lxc_utmp - Container running*

DMESG n'est pas beaucoup plus bavard...

*[64378.699884] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: None[64378.702417] ADDRCONF(NETDEV_UP): eth1: link is not
ready[64378.703358] ADDRCONF(NETDEV_CHANGE): eth1: link becomes
ready[64389.514779] eth1: no IPv6 routers present[64947.736211] e1000: eth1
NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None[64947.738740]
ADDRCONF(NETDEV_UP): eth1: link is not ready[64947.739686]
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready[64958.343388] eth1: no
IPv6 routers present*

Joris

Le 1 octobre 2014 11:48, Emmanuel Thierry <ml at sekil.fr> a écrit :

>
> Des logs lxc ou dmesg lorsque le container est lancé ?
>
> Manu
>
> Le 1 oct. 2014 à 11:45, Joris Michaux a écrit :
>
> J'ai oublié de préciser que quand les containers sont éteints, les 3
> interfaces fonctionnent correctement. (ping, ssh...)
>
> C'est à l'allumage des containers que le réseau tombe sur l'interface
> concernée.
>
> Typiquement :
>
> *Container 1 :*
>
>
>
>
>
>
> *lxc.utsname = frp2007culxc.network.type = physlxc.network.flags =
> uplxc.network.link = eth1lxc.network.ipv4 = 10.170.2.187/28
> <http://10.170.2.187/28>lxc.network.ipv4.gateway =
> 10.170.2.190lxc.network.hwaddr = 00:1E:01:61:5B:86*
>
> eth1 cesse de fonctionner lorsqu'elle est mappée à l'allumage du
> container. (du mode "phys")
>
> *Les commandes avant allumage du container :*
>
>
>
>
>
>
>
> *root at frp1007cu:/var/run/network# ip l1: lo: <LOOPBACK,UP,LOWER_UP> mtu
> 16436 qdisc noqueue state UNKNOWN mode DEFAULT     link/loopback
> 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0:
> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
> DEFAULT qlen 1000    link/ether 00:50:56:85:67:17 brd ff:ff:ff:ff:ff:ff3:
> eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
> mode DEFAULT qlen 1000    link/ether 00:1e:01:61:5b:86 brd
> ff:ff:ff:ff:ff:ff4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast state UP mode DEFAULT qlen 1000*
>     link/ether 00:1e:fd:d8:a3:44 brd ff:ff:ff:ff:ff:ff
>
> *Après :*
>
>
>
>
>
>
> *root at frp1007cu:/var/run/network# ip l1: lo: <LOOPBACK,UP,LOWER_UP> mtu
> 16436 qdisc noqueue state UNKNOWN mode DEFAULT     link/loopback
> 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0:
> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
> DEFAULT qlen 1000    link/ether 00:50:56:85:67:17 brd ff:ff:ff:ff:ff:ff4:
> eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
> mode DEFAULT qlen 1000    link/ether 00:1e:fd:d8:a3:44 brd
> ff:ff:ff:ff:ff:ff*
>
> Ce comportement me parait normal, et est confirmé sur les autres hosts de
> LXC.
>
> Joris
>
> Le 1 octobre 2014 11:34, Emmanuel Thierry <ml at sekil.fr> a écrit :
>
>>
>> Le 1 oct. 2014 à 11:28, Joris Michaux a écrit :
>>
>> Manu,
>>
>> Le problème est survenu à 7h12 hier. Heure à laquelle le trafic a balancé
>> sur le deuxième serveur fonctionnel. Sans redémarrage. Depuis j'ai
>> redémarré le container plusieurs fois, et même une fois la machine.
>>
>> # ip netns et ip netns list ne revoient rien.
>>
>>
>> Il faut commencer par ça. S'il n'y a rien c'est que le problème vient de
>> là vu que la création des namespace réseau a échoué.
>> Du coup les interfaces doivent encore exister sur le namespace de l'hôte,
>> si ce n'est pas le cas c'est que le problème vient du matériel ou des
>> drivers ethernet.
>>
>> Que donne un simple :
>> # ip l
>>
>> Par ailleurs, tu dois vérifier que les interfaces sont bien initialisées
>> dans le dmesg :
>> # dmesg
>>
>> Manu
>>
>>
>> Aucune iptables en place sur le host (ni le fonctionnel, ni l'autre).
>>
>>
>> J'ai des iptables sur deux hosts hébergeant les Reverse-Proxy Nginx, mais
>> pas sur les deux hosts hébergeant les webservers. Je tape sur le bon via
>> des tunnels ssl (stunnel4). Le fait qu'ils aient chacun une interface
>> dédiée m'évite les iptables à ce niveau.
>>
>> PS : la machine à problèmes a une sœur jumelle fonctionnelle sur laquelle
>> je peux comparer les configurations, ce que je n'arrête pas de faire depuis
>> hier.
>>
>> Merci !
>>
>> Joris
>>
>> Le 1 octobre 2014 11:11, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>
>>> Bonjour,
>>>
>>> As-tu redémarré les container ou bien le problème a-t-il eu lieu durant
>>> leur exécution ?
>>>
>>> Peux-tu exécuter les commandes suivantes ?
>>> # ip netns
>>> (pour chaque entrée de la liste => ${ns})
>>> # ip netns exec ${ns} ip l
>>> # ip netns exec ${ns} ip a
>>> # ip netns exec ${ns} ip r
>>> # ip netns exec ${ns} ip -6 r
>>> (et toute autre information utile comme les règles netfilter ou consors)
>>>
>>> Manu
>>>
>>> Le 1 oct. 2014 à 11:05, Joris Michaux a écrit :
>>>
>>> Bonjour à tous,
>>>
>>> Je vous écrit du fond de mon trou, je creuse depuis hier, et bientôt je
>>> ne pourrai plus sortir...
>>>
>>> *Contexte : *
>>> - 1 machine Debian 7 avec 3 interfaces :
>>>   |_ eth0 = 10.170.2.189
>>>   |_ eth1 = 10.170.2.187
>>>   |_ eth2 = 10.170.2.185
>>> - Rôle de la machine : héberger 2 containers LXC intégrant chacun un
>>> Apache
>>> - Configuration network des LXC : lxc.network.type = phys
>>>
>>> Le comportement du type "phys" de LXC est que l'interface ciblée est
>>> "aspirée" par le LXC (elle disparaît du ifconfig sur le host), et le
>>> container en bénéficie sans autre configuration.
>>>
>>> *Mon problème :*
>>> J'utilise ce mode de fonctionnement sur 5 machines en prod depuis 8
>>> mois, sans aucun problème. Depuis hier matin, les 2 LXC d'une des 5
>>> machines ont perdu le réseau, alors que les 8 autres continuent de
>>> fonctionner. Les configurations sont pupettisées, je ne vois pas comment
>>> elles auraient pu casser, sur une seule machine.
>>>
>>> Depuis hier je compare les fichiers de configuration des hôtes, des
>>> containers, les iptables, les routes, les tables arp... Je ne vois pas où
>>> est le problème.
>>>
>>> *Dernière chance :*
>>> J'ai créé un nouveau container sur ladite machine, et même tout neuf, il
>>> n'a pas de réseau.
>>>
>>>
>>> *Ma demande :Que vous ayez ou non déjà utilisé LXC, si vous avez
>>> n'importe quelle question bête à poser sur la configuration, ça peut
>>> m'éclairer sur un truc que je rate, et je vous en serai vraiment
>>> reconnaissant !*
>>>
>>> Merci à ceux qui me donneront quelques minutes !
>>>
>>> Joris M., un admin désemparé...
>>> _______________________________________________
>>> technique mailing list
>>> technique at lists.tetaneutral.net
>>> http://lists.tetaneutral.net/listinfo/technique
>>>
>>>
>>>
>>
>>
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.tetaneutral.net/pipermail/technique/attachments/20141001/4480daef/attachment.htm>