Forum général.général Approbation de design réseau basé sur debian.

Posté par  (site web personnel) .
Étiquettes :
2
13
juil.
2009
Bonjour,

Tout d'abord, merci de lire ce long thread et d'essayer de tout comprendre.
Merci aussi à ceux qui essayeront de m'aider.

Mon but est de discuter du design suivant :
http://niconux.be/files/network.png

Le tout serait basé sur Debian Lenny avec des switchs Cisco.
On devrait acheter deux switchs (ceux du bas) et aussi les serveurs. Pour les serveurs on est fixé, pour les switchs on pense soit à un Cisco 2960G-24TC-L soit un Cisco 3560G-24TS-S.

Tout ce qui se trouve au dessus des firewall est déjà en place dans l'infrastructure existante.

Description courte du schéma :

Tout est redondant, on élit un firewall maître avec VRRP. VRRP est actif pour les interfaces internes et externes sur les firewalls (74.1.1.2 et 74.1.1.3). Il y a aussi une redondance HSRP pour les routeurs. Le trunk entre les switchs et également redondant via EtherChannel.
Sur le lien rouge il y a le trafic conntrackd.

Il y aura 5 serveurs derrières les firewall, chaqu'un utilisant 2 interfaces pour le réseau de production, une pour le management et une interface pour une carte DRAC. Un de ces 5 serveurs ne sera pas connecté au réseau de production. J'aurai donc besoin de 25 interfaces pour connecter tout ce monde + 6 interfaces (2upstream & 2x2 trunk) sur les switchs. Cela me laisse 17 interfaces soit de quoi connecter 4 serveurs supplémentaires (en moyenne 4 liens par serveur).

Voici les questions que j'ai par rapport à ce design :

1° Le choix des switchs vous semble-t'il bon ?
2° Est-ce que je peut faire de l'ethernet bonding (côté serveur) sur deux switchs différents ?
3° Si il y a un problème sur le lien entre un serveur et le firewall actif, en partant du principe que j'utilise les options arp_ip_target et arp_interval_options du module de bonding, est-ce que le serveur va utiliser son autre interface pour joindre le firewall ?
4° Si une interface de serveur tombe, il utilisera l'autre. A ce moment là, le kernel devrait envoyer un gratuitous ARP pour notifier les autres machines dans le broadcast domain du changement d'adresse MAC. Les autres machines vont-elle écouter ce ARP update et mettre à jour leurs caches ARP ?
5° Si le firewall actif change, le kernel du nouveau firewall enverra un gratuitous ARP sur demande de vrrpd, correcte ?

Merci beaucoup pour votre patiente.
  • # Re:

    Posté par  (site web personnel) . Évalué à 5.

    1° Le choix des switchs vous semble-t'il bon ?

    difficile à dire sans connaitre ton trafic ni plus d'info sur ton archi.
    je dispose des deux modèles, ils sont globalement très bien, la gamme 3560 est plus taillée pour faire du routage tandis que les 2960 sont des switchs niveau 2 basiques.
    après j'ai des soucis a faire de l'iSCSI sur des 2960 (paquets droppés par le switchs) mais les 3560 n'ont pas de buffers bcp plus gros et ont va devoir passer sur du 3750

    2° Est-ce que je peut faire de l'ethernet bonding (côté serveur) sur deux switchs différents ?

    ça dépend de ce que tu appelle "ethernet bonding", nous on fait du bonding actif/passif "de base" et ça marche très bien, ça change de port et repart très vite.

    si tu veut faire du lacp sur deux switchs distinct c'est possible mais pas avec les modèles que tu a selectionner. il faut en face des switchs stackable (gamme 3750 par exemple).

    3° Si il y a un problème sur le lien entre un serveur et le firewall actif, en partant du principe que j'utilise les options arp_ip_target et arp_interval_options du module de bonding, est-ce que le serveur va utiliser son autre interface pour joindre le firewall ?

    don't know

    4° Si une interface de serveur tombe, il utilisera l'autre. A ce moment là, le kernel devrait envoyer un gratuitous ARP pour notifier les autres machines dans le broadcast domain du changement d'adresse MAC. Les autres machines vont-elle écouter ce ARP update et mettre à jour leurs caches ARP ?

    euh normalement non, quand tu va monter le bonding tu n'aura plus qu'une adresse mac

    5° Si le firewall actif change, le kernel du nouveau firewall enverra un gratuitous ARP sur demande de vrrpd, correcte ?

    c'est quoi ton firewall ?
    mais normalement le VRRP c'est a base d'adresse MAC virtuelles pareil, donc non. c'est juste la table de MAC du/des switchs qui va être mise a jour.
    • [^] # Re: Re:

      Posté par  (site web personnel) . Évalué à 1.

      Il y aura 5 serveurs derrières les firewall, chaqu'un utilisant 2 interfaces pour le réseau de production, une pour le management et une interface pour une carte DRAC.

      Pourquoi une interface physique a part pour le management si c'est pour le brancher sur le même switch au final ?
      Fait plutôt des vlans sur ton bonding

      Un de ces 5 serveurs ne sera pas connecté au réseau de production. J'aurai donc besoin de 25 interfaces pour connecter tout ce monde

      Ah ?
      4*4 + 1*2 => 18 chez moi
      • [^] # Re: Re:

        Posté par  (site web personnel) . Évalué à 1.

        Merci pour tes réponses :)

        1° Le traffic en question est moyen, ce sont principalement des services DNS (autoritaire et resolver), SMTP (relay et MX) et hosting fourni par un ISP de classe moyenne. Vu qu'on fait pas d'iSCSI, le 2960 devrait suffire je pense (il y a aussi du management réseau). Je doit encore investiguer mais ça tiens sur des switches 100mbps actuellement donc là ça devrait d'office aller.

        2° Ethernet bonding en faillover donc mode actif/passif.
        3° Ok, quelqu'un a une idée ?
        4° Donc autant en VRRP qu'en ethernet bonding on utilise une adresse MAC virtuelle ?
        Dans ce cas, autant en VRRP qu'en ethernet bonding, comment est-ce que cela marche pour que les switches comprennent que l'adresse mac virtuelle n'est plus sur le port X mais sur un port Y ?
        5° Les firewalls seront des box iptables tournant sous Debian Lenny.

        Également :
        - Interface de management : L'idée de base c'est surtout d'éviter de surcharger le réseau de production parce-qu'il y aura des backups vers un NAS sur ce réseau et également des homedir potentiellement volumineuse en NFS. Je ne sais pas si tu pense que c'est ou non exagéré ?

        - Nombre d'interface : en fait le serveur qui n'est pas connecté en prod est connecté à un autre réseau privé (ce qui fait 3interfaces, donc 19) et aussi deux upstream sur les switches et deux fois deux trunk donc 25 ports utilisés en tout (sur 48).

        Merci beaucoup.
        • [^] # Re: Re:

          Posté par  (site web personnel) . Évalué à 1.

          2° Ethernet bonding en faillover donc mode actif/passif.
          du bonding en mode=1 quoi, alors pas de soucis tu peut te mettre sur deux switchs distincts.

          3° Ok, quelqu'un a une idée ?
          fait plutot du miimon, exemple:
          options bonding mode=1 miimon=200 downdelay=200 updelay=200

          les options de bonding sont la pour détecter si l'interface marche ou pas, les arp_* sont
          une solution de backup si tu ne peut pas utiliser l'état physique de l'interface, auquel cas
          tu utilise une adresse mac proche (le switch de preference).

          4° Dans ce cas, autant en VRRP qu'en ethernet bonding, comment est-ce que cela marche pour que les switches comprennent que l'adresse mac virtuelle n'est plus sur le port X mais sur un port Y ?

          Basiquement la table ARP est nettoyée lorsque les interfaces associés passent down (celle d'un switch down ou celle d'un serveur), de la deux possibilité: si ton serveur est le plus "rapide" a parler sur la nouvelle interface: l table arp du switch est mise a jour, sinon si c'est un paquet a destination de ton serveur qui arrive en premier le paquet est broadcasté et la reponse de ton serveur est utilisée pour mettre a jour la table ARP

          C'est la base du problème de sécu réseau chez ovh d'il y a qques temps ( http://www.linuxfr.org/forums/12/27292.html )

          5° Si le firewall actif change, le kernel du nouveau firewall enverra un gratuitous ARP sur demande de vrrpd, correcte ?

          cf source de vrrpd, a priori oui.
          toutefois en théorie en VRRP l'adresse IP est associée a une MAC virtuelle qui n'est pas sensée changer, donc pas besoin de gratuitous arp
    • [^] # Re: Re:Hors sujet

      Posté par  (site web personnel) . Évalué à 1.

      Question totalement hors-sujet, mais avec quel soft as tu fais ton schéma?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.