[technique] lxc.network.type = phys

Mer 1 Oct 11:45:14 CEST 2014

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/2874832c/attachment.htm>