Problème connexion ssh/http avec bridge et 802.1Q

Support Debian
#1

Bonjour,

J’ai un petit soucis sur une architecture réseau(assez bizarre certes):

  • un routeur cisco qui gère mon interconnexion à internet et qui possède des interfaces taggées en 802.1Q (VLAN 1 a 10)
  • une machine (debian etch) en bridge
  • un switch cisco qui gère mes vlans
  • les utilisateurs branchés a ce switch.

les utilisateurs arrivent a sortir sur internet, je peux visualiser le trafic sur br0

Par contre, impossible de se connecter en ssh ou en http sur le bridge qui possède un serveur web et ssh.

J’ai donc tenté de créer une interface br0.2 qui est taggée et appartient au vlan2.
Avec cette methode, je peux me connecter en ssh, mais la connexion est plus qu’instable, quand je lance une commande qui demande un retour un peu trop important (type ifconfig) la connexion se fige et je ne peux plus rien faire… la connexion a l’interface web avec l’ip de br0.2 est toujours impossible.

Je ne vois pas trop comment faire pour sortir de la… y aurait-il une méthode pour mettre une interface en trunk sous linux ?
Y aurait-il une variable dans ssh ou apache qui empècherai la connexion de se faire ? une limite sur la taille des paquets ou autre ?

J’ai capturé les trames lorsque j’initie une connexion depuis un client sur le vlan2 vers le serveur web, si cela peut vous aider je vous la mettrai a disposition.

Merci d’avance pour votre aide

#2

Une ptite aide svp ? :cry:

#3

Je n’ai jamais fait de pont avec du trafic VLAN taggé, mais j’aurais procédé de la même façon que toi, donc pas trop d’idée. Je veux bien les captures de paquets en précisant bien sur quelle interface elles sont faites (interface VLAN, interface pont et interface physique, les trois pour comparer ce serait bien).

Le symptôme fait penser à un problème de MTU (taille de paquet maximum). Que donne tcptraceroute vers l’adresse IP du serveur ? Que donnent des pings de taille croissante jusqu’à 1472 octets de données (paquet de 1500 octets) ? Qu’est-ce que ça donne en limitant la MTU de l’interface VLAN à 1496 ?

Quelle est la version du noyau ? Le filtrage par netfilter/iptables des trames pontées est-il activé (/proc/sys/net/bridge/bridge-nf-filter-vlan-tagged) ? Il y a un bug dans le pilote VLAN des noyaux antérieurs à 2.6.21 qui peut provoquer la corruption des paquets lorsqu’ils traversent netfilter.

#4

Bonjour PascalHambourg, merci pour ta réponse.

Pour les trames tu pourras les trouver ici : http://dudu.is.free.fr/trames/captures.rar

J’ai capturé les interfaces lo, br0 et br0.2 au moment ou j’initie une connexion vers mon serveur web.

Je suis sur un noyau 2.6.18 et /proc/sys/net/bridge/bridge-nf-filter-vlan-tagged est bien activé. Peut-etre est-ce cela qui pose soucis… penses-tu qu’il faille mettre a jour le noyau obligatoirement ?

Pour ce qui est du MTU je vais essayer ça tout de suite… je te tiens au courant.

Merci pour ton aide.

#5

Merci pour les captures mais tu aurais pu utiliser un format d’archive plus ouvert et standard que rar, par exemple le bon vieux tar.gz. Passons.

Sur br0.2 et br0 on voit la même chose : le serveur envoie deux segments de données de 1448 et 716 octets respectivement, mais le client n’envoie un acquittement sélectif (sack) que pour le second, comme s’il n’avait pas reçu le premier. Le serveur s’évertue à réémettre le premier segment, en vain.

Il aurait été intéressant de faire une capture sur l’interface ethernet physique également, voire sur le switch et le client, pour voir à quel endroit le segment est perdu. Par contre la capture sur l’interface de loopback n’a pas d’intérêt, ce n’est pas là que ça se passe.

Le pont a-t-il des règles iptables ou ebtables ?
Si non, tu peux essayer de mettre /proc/sys/net/bridge/bridge-nf-filter-vlan-tagged à 0 pour voir si ça améliore.
Le switch fait-il du filtrage IP ?

Je n’ai pas réussi à reproduire le problème sur une machine de test avec un noyau 2.6.20 donc censé avoir le bug que j’ai mentionné plus haut, tout marche. Je n’ai pas de machine tournant sous etch avec un noyau 2.6.18 Debian sous la main, ni de noyau plus vieux que 2.6.20.

Tu as parlé de trunk, s’agit-il de channel bonding (agrégation de liens ethernet) ?

Je sais que certaines cartes ethernet posent des problèmes en mode VLAN taggé car elles ne permettent pas d’émettre ou recevoir des trames de 1500 octets + le tag (4 octets supplémentaires). Mais si le pont fonctionne, le problème doit être ailleurs.

#6

Bonjour PascalHambourg !

Désolé pour le format de l’archive j’ai fait ça vite sans réfléchir… :blush:

Par contre… MERCI BEAUCOUP !!

Tu avais vu juste dans ton premier message c’était bien un problème de MTU, je l’ai passé a 1496 comme tu me l’as recommandé et cela fonctionne parfaitement ! Plus aucune coupure via ssh et un accès impeccable au serveur web… super !!

je pense que ta dernière phrase résume bien le problème : “Je sais que certaines cartes ethernet posent des problèmes en mode VLAN taggé car elles ne permettent pas d’émettre ou recevoir des trames de 1500 octets + le tag (4 octets supplémentaires).”

C’est a mon avis exactement ce qu’il s’est passé !

Encore merci pour ton aide plus que précieuse !!

Bonne continuation !

#7

Bizarre qu’un archiveur sous GNU/Linux applique le format RAR par défaut, quand même. :stuck_out_tongue:

Quand les petites quantités de données passent mais pas les grosses, il ne faut pas être grand clerc pour penser à la MTU, qui est en haut de la liste des suspects habituels pour ce symptôme.

Je suis quand même perplexe :confused: : si ça vient d’une limitation de la carte ethernet alors logiquement les communications internet taggées traversant le pont devraient aussi être affectées, à moins qu’elles ne mettent pas en jeu de paquets de taille maximum. Par curiosité quelles est le modèle de la carte ethernet du pont côté switch ?

#8

Bizarre qu’un archiveur sous GNU/Linux applique le format RAR par défaut, quand même.<< non non c’est moi qui ai mis rar mais j’avais pas réfléchi a ça ^^ encore désolé !

Je suis encore plus ou moins novice donc je n’ai pas encore tous les bons réflexes… :confused:

En fait la communication vers internet à l’air de se faire via l’interface br0. La br0.2 sert seulement à la connexion ssh/web a priori.

Pour ce qui est des cartes réseaux, la carte coté routeur est une netgear et coté switch c’est une realtek.

Cet après midi je testerai ça sur une machien différente, je te dirai si le problème est le même ou non.

Encore merci

bonne journée

#9

Justement, le réglage de la MTU sur l’interface VLAN n’agit que sur les communications avec le serveur. Les communications avec internet passent aussi par la carte ethernet physique (ethX) côté switch et donc devraient être affectées par une limitation de taille de paquets de celle-ci (ou de son pilote).

Quel modèle, la Realtek ? J’ai fait mon essai avec une bête carte fast ethernet RTL8139.

#10

Je viens de tester sur une autre machine avec une carte mère intel et 2 interfaces réseaux intégrées, même topo, avec le mtu a 1500 impossible de se connecter aux serveurs web et ssh. Je passe en 1496 comme sur l’autre machine et plus aucun problème… donc a priori ca ne depend pas de la carte réseau a priori.

En effet c’est assez étonnant que les communications vers internet ne soient pas affectées… :confused:

Pour la carte réseau c’est une realtek intégrée a une carte mere VIA.