Non, ça n'est pas tordu (c est assez classique en fait) et les serveurs n'ont pas a avoir plusieurs interfaces.
Je vais essayé de faire un petit schéma en espérant que ça passera bien:
tu essaies de joindre le serveur 2, sauf que switch1 est mettre VRRP sur ce VLAN donc ca part vers lui, ca passe par la rocade pour aboutir au serveur2.
Le retour, par contre, est directe: serveur2 - switch2 - routeur - WAN
Le problème c'est que les entrées de la table mac (faisant le lien entre @MAC et port du switch) disparaissent (timeout) beaucoup plus vite que celles de la table ARP (@MAC - @IP).
Et donc parfois, si le switch1 recoit un paquet a destination de serveur2 il a encore dans sa table ARP mais pas dans sa table MAC.
Il n'envoie pas de requete ARP, ca servirait à rien vu qu'il l'a toujours l'entrée dans sa table ARP, mais il ne sait pas par quelle interface balancer le paquet: méthode bourrin: il flood sur toutes les interfaces, y compris la rocade et donc serveur2 obtient bien son paquet. Par contre, serveur1 (qui est dans le même VLAN) l'a également reçu.
C'est assez effrayant qu'OVH dise que c'est "normal" qu'un client reçoive des paquets (peut-être confidentiel) d'un autre client...
[^] # Re: broadcast != flood
Posté par nicolasi . En réponse au message sécurité réseau chez OVH. Évalué à 6.
Je vais essayé de faire un petit schéma en espérant que ça passera bien:
serveur1 ----- switch1 ------------------
| |
| |
Rocade Routeur -------- WAN
| |
| |
serveur2 ----- switch2 ------------------
tu essaies de joindre le serveur 2, sauf que switch1 est mettre VRRP sur ce VLAN donc ca part vers lui, ca passe par la rocade pour aboutir au serveur2.
Le retour, par contre, est directe: serveur2 - switch2 - routeur - WAN
Le problème c'est que les entrées de la table mac (faisant le lien entre @MAC et port du switch) disparaissent (timeout) beaucoup plus vite que celles de la table ARP (@MAC - @IP).
Et donc parfois, si le switch1 recoit un paquet a destination de serveur2 il a encore dans sa table ARP mais pas dans sa table MAC.
Il n'envoie pas de requete ARP, ca servirait à rien vu qu'il l'a toujours l'entrée dans sa table ARP, mais il ne sait pas par quelle interface balancer le paquet: méthode bourrin: il flood sur toutes les interfaces, y compris la rocade et donc serveur2 obtient bien son paquet. Par contre, serveur1 (qui est dans le même VLAN) l'a également reçu.
C'est assez effrayant qu'OVH dise que c'est "normal" qu'un client reçoive des paquets (peut-être confidentiel) d'un autre client...
Nicolas