[technique] lxc.network.type = phys

[Emmanuel Thierry]

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 = frp2007cu
> lxc.network.type = phys
> lxc.network.flags = up
> lxc.network.link = eth1
> lxc.network.ipv4 = 10.170.2.187/28
> lxc.network.ipv4.gateway = 10.170.2.190
> lxc.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 l
> 1: 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:00
> 2: 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:ff
> 3: 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:ff
> 4: 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 l
> 1: 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:00
> 2: 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:ff
> 4: 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/81fcad63/attachment.htm>