Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Basculement CLUSTER non fonctionnel lors du retour du PFsense MASTER

    Français
    4
    9
    1479
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      tdanel last edited by

      Bonjour à tous,

      Nous avons installé un cluster de PFSENSE dans le cadre d’une évolution d’une infrastructure de production.

      Les 2 machines utilisées sont rigoureusement identique DELL R320
      Nous avons installé dans chacune des machines une carte fibre dual port.

      Coté Interface
      L’interface WAN est un LAGG des 2 interfaces fibres. le LAGG est configuré en LACP
      Une interface physique à été configurée comme "LAN" que pour avoir un accès web, en temps normal, cette interface n’est pas câblée. Elle est utilisée qu'en cas de problème.
      Nous avons créé des VLANs associés à l’interface LAGG.
      L’interface LAGG reçoit à la fois des flux provenant de l’extérieur (interconnexion opérateur); elle véhicule aussi des flux interne (inter-VLANs).
      Une interface physique des serveurs a été dédiée pour la synchronisation PFSYNC pour la synchronisation du cluster avec mise en place des règles nécessaire pour assurer la synchronisation des 2 pfsenses.
      Nous avons créé des interfaces associées aux VLANs
      • Sur le MASTER : IP1
      • Sur le SLAVE : IP2
      • Sur le master nous avons créé une CARP associé aux interfaces avec une IP3.
      Nous avons plus de 15 CARPs de configurées en IPV4 et IPV6

      Coté Service
      Nous utilisons les 2 pfsenses pour
      • Serveur IPSEC
      • Serveur DHCP (pour quelques VLANs)
      • Serveur DNS resolver
      • Serveur NTP

      Afin de simplifier les règles de filtrages nous avons créé des "interfaces groups" afin de regrouper les VLANs de même type (LAN bureautique, LAN administration financière, interco, etc ..). Des règles de filtrage ont été mise en place sur les « interface groups »

      Pour le NAT nous avons utilisé du NAT OUTBOUND ( Hybrid Outbound NAT rule generation)

      Version des Pfsenses
      Les 2 pfsenses ont été installée en version 2.2.3.
      Nous n’avons ajouté aucun package supplémentaires.

      Notre problème :
      En fonctionnement normal :
      Le MASTER rempli son rôle, Les CARPs sont MASTER, le trafic passe par lui, les serveurs DHCPs, DNS, IPSEC etc sont tous fonctionnel.
      Le SLAVE est en attente avec les CARPs en BACKUP.

      On coupe le PFSENSE MASTER : le SLAVE prend la main, les CARPs basculent MASTER, les serveurs DHCP, DNS, IPSEC etc .. basculent sans problème. Le temps de la bascule on perd 3 pings vers les interconnexions de transit. –> tout vas bien !

      On relance le PFSENSE MASTER : les CARPs reviennent MASTER sur le Pfsense MASTER, et bascule en BACKUP sur le Pfsense SLAVE. Mais la bascule semble n’être que visuelle; a ce moment là, on perd toutes connectivité vers l’extérieur, le serveur IPSEC tombe, etc …

      En effectuant une recherche ARP, on constate que les requêtes partent toujours vers le SLAVE.

      Le reboot du Pfsense SLAVE permet au PFsense MASTER de reprendre totalement la main, et rendre à nouveau le service ( interco, IPSEC etc .. )

      Nous avons essayé de resetter complètement le Pfsense SLAVE, (à travers le menu CLI : 4 reset to factory default), réinstaller les interfaces à la main, récréer les liens PFSYNC, etc ..
      Une fois la synchronisation effectuée entre les 2 PFsenses, nous avons toujours constaté le problème.

      Quelqu'un aurait une piste de recherche ?
      Merci d'avance pour votre aide.

      --
      Thierry

      1 Reply Last reply Reply Quote 0
      • C
        ccnet last edited by

        Ça nous change un message initial où l'on des données pour comprendre la configuration !
        Des informations dans les logs de Pfsense  ?

        1 Reply Last reply Reply Quote 0
        • T
          tdanel last edited by

          Bonjour,

          Voici ce que j'ai pu trouver sur le SLAVE

          
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan990
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan680
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan884
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan991
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan358
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan530
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan885
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan357
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan529
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan886
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan871
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan887
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan356
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan528
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan870
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan880
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan519
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan881
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan984
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan532
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan997
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan982
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan522
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan996
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan983
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan523
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan520
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan981
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan993
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan89
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan676
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan526
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan873
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan992
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan677
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan527
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan872
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan995
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan678
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan524
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan875
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan994
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan15
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan679
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan525
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan874
          Aug 7 18:19:00	pfSense check_reload_status: Carp backup event
          Aug 7 18:19:00	pfSense check_reload_status: Linkup starting lagg0_vlan480
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for WAN(wan) but ignoring since interface is configured with static IP ( )
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "194.199.220.17 - IP Virtuelle FailOver VLAN990 (55@lagg0_vlan990)" has resumed the state "BACKUP" for vhid 55@lagg0_vlan990
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN990(opt38) but ignoring since interface is configured with static IP (194.199.220.20 )
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0_vlan990
          Aug 7 18:19:01	pfSense php-fpm[55763]: /rc.linkup: Hotplug event detected for VLAN680(opt28) but ignoring since interface is configured with static IP (192.168.103.253 )
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0_vlan680
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "192.168.103.254 - IP Virtuelle FailOver VLAN680 (42@lagg0_vlan680)" has resumed the state "BACKUP" for vhid 42@lagg0_vlan680
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN884(opt17) but ignoring since interface is configured with static IP (10.117.17.252 )
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0_vlan884
          Aug 7 18:19:01	pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "10.117.17.250 - IP Virtuelle FailOver VLAN884 (19@lagg0_vlan884)" has resumed the state "BACKUP" for vhid 19@lagg0_vlan884
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN358(opt32) but ignoring since interface is configured with static IP (192.168.100.239 )
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0_vlan358
          Aug 7 18:19:01	pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "192.168.100.240 - IP Virtuelle FailOver VLAN358 (46@lagg0_vlan358)" has resumed the state "BACKUP" for vhid 46@lagg0_vlan358
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "194.199.220.124 - Ip FailOver VLAN530 (56@lagg0_vlan530)" has resumed the state "BACKUP" for vhid 56@lagg0_vlan530
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN530(opt21) but ignoring since interface is configured with static IP (194.199.220.125 2001:660:302d:4011::1)
          Aug 7 18:19:01	pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "2001:660:302d:4011::10 - IPv6 FailOver VLAN530 (57@lagg0_vlan530)" has resumed the state "BACKUP" for vhid 57@lagg0_vlan530
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0_vlan530
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN885(opt18) but ignoring since interface is configured with static IP (10.117.41.252 )
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0_vlan885
          Aug 7 18:19:01	pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "10.117.41.250 - IP Virtuelle FailOver VLAN885 (20@lagg0_vlan885)" has resumed the state "BACKUP" for vhid 20@lagg0_vlan885
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "10.217.255.250 - IP Virtuelle FailOver VLAN357 (3@lagg0_vlan357)" has resumed the state "BACKUP" for vhid 3@lagg0_vlan357
          Aug 7 18:19:01	pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "2001:660:302d:4357::1:1 - IPV6 Virtuelle FailOver VLAN357 (32@lagg0_vlan357)" has resumed the state "BACKUP" for vhid 32@lagg0_vlan357
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN357(opt2) but ignoring since interface is configured with static IP (10.217.255.252 2001:660:302d:4357::1)
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0_vlan357
          Aug 7 18:19:01	pfSense php-fpm[55763]: /rc.linkup: Hotplug event detected for VLAN886(opt19) but ignoring since interface is configured with static IP (10.255.255.252 )
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0_vlan886
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "10.255.255.250 - IP Virtuelle FailOver VLAN886 (3@lagg0_vlan886)" has resumed the state "BACKUP" for vhid 3@lagg0_vlan886
          Aug 7 18:19:01	pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN871(opt10) but ignoring since interface is configured with static IP (10.117.25.62 )
          Aug 7 18:19:01	pfSense check_reload_status: rc.newwanip starting lagg0_vlan871
          Aug 7 18:19:01	pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "10.117.25.60 - IP Virtuelle FailOver VLAN871 (27@lagg0_vlan871)" has resumed the state "BACKUP" for vhid 27@lagg0_vlan871
          Aug 7 18:19:18	pfSense php-fpm[55763]: /rc.carpmaster: Carp cluster member "192.168.100.240 - IP Virtuelle FailOver VLAN358 (46@lagg0_vlan358)" has resumed the state "MASTER" for vhid 46@lagg0_vlan358
          Aug 7 18:19:22	pfSense check_reload_status: updating dyndns GW_VLAN996
          Aug 7 18:19:22	pfSense check_reload_status: Restarting ipsec tunnels
          Aug 7 18:19:22	pfSense check_reload_status: Restarting OpenVPN tunnels/interfaces
          Aug 7 18:19:34	pfSense php-fpm[31757]: /rc.newipsecdns: IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
          Aug 7 18:19:34	pfSense check_reload_status: Reloading filter
          Aug 7 18:19:34	pfSense php-fpm[31757]: /rc.newipsecdns: WARNING: Setting i_dont_care_about_security_and_use_aggressive_mode_psk option because a phase 1 is configured using aggressive mode with pre-shared keys. This is not a secure configuration.
          Aug 7 18:19:34	pfSense php-fpm[31757]: /rc.newipsecdns: Forcefully reloading IPsec
          Aug 7 18:19:34	pfSense check_reload_status: Reloading filter
          Aug 7 18:19:34	pfSense php-fpm[31757]: /rc.newipsecdns: WARNING: Setting i_dont_care_about_security_and_use_aggressive_mode_psk option because a phase 1 is configured using aggressive mode with pre-shared keys. This is not a secure configuration.
          Aug 7 18:19:38	pfSense php-fpm[69294]: /rc.newipsecdns: IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
          Aug 7 18:19:38	pfSense check_reload_status: Reloading filter
          Aug 7 18:19:38	pfSense php-fpm[69294]: /rc.newipsecdns: WARNING: Setting i_dont_care_about_security_and_use_aggressive_mode_psk option because a phase 1 is configured using aggressive mode with pre-shared keys. This is not a secure configuration.
          Aug 7 18:19:38	pfSense php-fpm[69294]: /rc.newipsecdns: Forcefully reloading IPsec
          Aug 7 18:19:38	pfSense check_reload_status: Reloading filter
          Aug 7 18:19:38	pfSense php-fpm[69294]: /rc.newipsecdns: WARNING: Setting i_dont_care_about_security_and_use_aggressive_mode_psk option because a phase 1 is configured using aggressive mode with pre-shared keys. This is not a secure configuration.
          Aug 7 18:21:34	pfSense login: login on ttyv0 as root
          Aug 7 18:21:38	pfSense check_reload_status: Linkup starting bge1
          Aug 7 18:21:38	pfSense kernel: bge1: link state changed to DOWN
          Aug 7 18:21:39	pfSense php-fpm[28220]: /rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.168.1.2 )
          
          
          1 Reply Last reply Reply Quote 0
          • P
            prov last edited by

            Bonjour,

            Peux-tu nous indiquer la configuration de tes @VIP CARP ?
            Notamment les valeurs de "advbase" et "advskew" pour le master et pour le slave ?

            1 Reply Last reply Reply Quote 0
            • T
              tdanel last edited by

              Bonjour,

              Voici un exemple de configuration sortie du fichier de conf du PF MASTER

              
               <vip><mode>carp</mode>
              	<interface>opt35</interface>
              	<vhid>37</vhid>
              	<advskew>0</advskew>
              	<advbase>1</advbase>
              	<password>je_vous_le_donne_pas</password>
              
              	<type>single</type>
              	<subnet_bits>29</subnet_bits>
              	<subnet>192.168.20.4</subnet></vip> 
              
              

              Concernant les valeurs "advbase" et "advskew" :
              Sur le MASTER

              
              <advskew>0</advskew>
              <advbase>1</advbase>
              
              

              Sur le SLAVE

              
              <advskew>100</advskew>
              <advbase>1</advbase>
              
              

              Lors de la création des CARPs à travers l'interface web de configuration, nous n'avons pas touchées à ces valeurs. Il me semble de PFSENSE s'occupe lui même de les ajuster.

              –
              Thierry

              1 Reply Last reply Reply Quote 0
              • T
                tdanel last edited by

                Bonjour à tous,

                Personne n'a une idée ? une piste de réflexion ? un soupçon de … je sais pas moins ... quelques choses ?

                Bien Cordialement

                Thierry

                1 Reply Last reply Reply Quote 0
                • C
                  ccnet last edited by

                  Je pense qu'il va falloir poster d'avantage d'éléments sur votre configuration. Je vois opt38 dans les logs … ce qui laisse supposer une configuration complexe avec beaucoup de vlans ....

                  1 Reply Last reply Reply Quote 0
                  • J
                    Juve last edited by

                    si je résume :

                    • CARP fonctionne bien car les noeuds se voient et les VIP basculent aller /retour
                    • pfSync fonctionne a priori car vous ne semblez pas constater de drop des sessions TCP en cours durant une bascule ( vous ne le dite pas mais vous l'auriez constaté)

                    Quel est le type d'equipement reseau ?

                    Pouvez vous faire un tcpdump sur l'interface du maitre quand ce produit le phenomene ? l'objectif etant de voir si il recoit les arp-who-has.
                    Si il les recoit et qu'il ne repond pas (alors qu'il devrait), il faudra investiguer cote freeBSd du serveur maitre.

                    1 Reply Last reply Reply Quote 0
                    • T
                      tdanel last edited by

                      Le CARP fonctionne coté PFSENSE.
                      il fallait en effet regarder du coté de FREEBSD …

                      Lorsque l'équipement MASTER disparait (perte de connexion, reboot) l'équipement SLAVE constate la bascule et reprends les adresses CARP, les équipements réseaux adaptent les tables ARP (passage à l'état inactif des interfaces sur l'équipement MASTER) et le service est toujours rendu.

                      Mais lorsque le MASTER revient à la vie, le SLAVE, ne perdant pas la connection réseau, le routeur continue à penser que le SLAVE est MASTER.
                      L'une des solution pour provoquer la mise à jour de la table ARP du routeur, a été de rebooter le SLAVE (passage des interfaces physique à DOWN) pour provoquer le flapping des interfaces réseaux. L'autre solution consiste à faire un clear de la table ARP des routeurs.

                      C’est en faisant des TCPDUMPs que nous avons constaté en faite que le PFSENSE ne faisait pas de gratuitous ARP lors de la bascule CARP du SLAVE au MASTER.

                      Pour pouvoir forcer ces annonces, nous avons

                      • installer le package ARPING sur les PFSENSES
                      • modifier le script /etc/rc.carpmaster pour y intégrer la commande : /usr/local/sbin/arping -C 5 -i moninterface -S monadressesource monadresssdestination

                      au reboot, le master préviens le switch qu’il est là …. la table ARP se mets à jour, et le basculement du réseau est opérationnel.

                      Est-ce le comportement normal d'un cluster de PfSense ? Quelqu'un a-t-il déjà rencontré ce problème ?

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post

                      Products

                      • Platform Overview
                      • TNSR
                      • pfSense Plus
                      • Appliances

                      Services

                      • Training
                      • Professional Services

                      Support

                      • Subscription Plans
                      • Contact Support
                      • Product Lifecycle
                      • Documentation

                      News

                      • Media Coverage
                      • Press
                      • Events

                      Resources

                      • Blog
                      • FAQ
                      • Find a Partner
                      • Resource Library
                      • Security Information

                      Company

                      • About Us
                      • Careers
                      • Partners
                      • Contact Us
                      • Legal
                      Our Mission

                      We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                      Subscribe to our Newsletter

                      Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                      © 2021 Rubicon Communications, LLC | Privacy Policy