https://docs.mitigator.ru/v26.08/en/tags/network-integration/ Hugo en https://docs.mitigator.ru/v26.08/en/kb/deploy/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/en/kb/deploy/ Terminology and methods for implementing the MITIGATOR DDoS protection system into the network. External and Internal Networks Logically MITIGATOR is connected to two networks: External network (external) – the network from which the traffic that needs cleaning comes; Internal network (internal) – the network in which the protected resources are located. https://docs.mitigator.ru/v26.08/en/install/multi/workers/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/en/install/multi/workers/ The following steps assume that an instance of MITIGATOR has already been installed. Otherwise, perform the installation using one of the following methods. Before setting up a cluster, you must set up a virtual network (VPN). It needs network connectivity between instances to work. Detailed information on setting up and the necessary access are described at the link. Common databases for all MITIGATOR instances are physically stored on the server of one of them. The base instance must be allowed connections from other instances on the following TCP ports: 8888, 2003, 3080, 5432. https://docs.mitigator.ru/v26.08/en/install/multi/failover/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/en/install/multi/failover/ The following steps assume that an instance of MITIGATOR has already been installed. Otherwise, perform installation using one of the following methods. Before configuring a cluster, you must configure Virtual network(VPN). It needs network connectivity between instances to work. Detailed information on setting up and the necessary access are described at the link. For fault tolerance, synchronized copies of the database must be physically stored on different servers (replicated). With this scheme, database replicas are stored on the same servers where MITIGATOR instances are running. This saves resources and does not require knowledge of PostgreSQL configuration. https://docs.mitigator.ru/v26.08/en/install/multi/custom/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/en/install/multi/custom/ The following steps assume that an instance of MITIGATOR has already been installed. Otherwise, install it using one of the following methods first. Before configuring a cluster, you must configure virtual network (VPN). It needs network connectivity between instances to work. Detailed information on setting up and necessary accesses are described by the link. This deployment scheme implies the physical storage of databases common to all MITIGATOR instances on an external server. The performance and fault tolerance of all DBMS is ensured by the administrator of the external server for specific requirements. https://docs.mitigator.ru/v26.08/en/install/multi/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/en/install/multi/ In cluster mode, several instances of the MITIGATOR system use common databases and are centrally managed. By adding additional instances, the system allows unlimited scaling. Cluster mode allows you to process traffic independently on each instance, but manage them from a single interface. In the event of a planned or emergency shutdown of any instance, the ability to manage the rest remains. Deployment Virtual network (VPN) is configured between instances. It needs network connectivity between instances to work. Detailed information on setting up and the necessary access is available by the link. https://docs.mitigator.ru/v26.08/en/install/multi/hybrid/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/en/install/multi/hybrid/ deployment schemes can be combined when building a cluster. Example: Failover Storage with Additional Filtering Nodes With this implementation scheme, database copies are stored on different servers (replicated), but the number of database replicas is less than the number of MITIGATOR instances in the cluster. Some instances access remote databases via TCP ports: 8888, 2003, 3080, 5432. In this example, the graphite and logan are included as external modules. https://docs.mitigator.ru/v26.08/en/kb/bypass/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/en/kb/bypass/ MITIGATOR supports hardware bypass of Silicom and LR-Link adapters. Tested Silicom adapters: PE2G4BPI35LA Quad Port Copper 1G Ethernet PCIe Bypass Network Adapter (Intel i350AM4) PE2G6BPI35 Six Port Copper 1G Ethernet PCIe Bypass Network Adapter (Intel i350AM4) PE210G2BPI9 Dual Port Fiber 10G Ethernet PCIe Bypass Network Adapter (Intel 82599ES) PE310G4BPI71 Quad Port Fiber 10G Ethernet PCIe Bypass Network Adapter (Intel XL710BM1) PE340G2BPI71 Dual Port Fiber 40G Ethernet PCIe Bypass Network Adapter (Intel XL710) P4CG2BPI81 Dual Port Fiber 100G Ethernet PCIe Gen 4.0 Bypass Network Adapter (Intel E810) Tested LR-Link adapters: https://docs.mitigator.ru/v26.08/en/kb/bgp-state/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/en/kb/bgp-state/ To ensure uninterrupted traffic through the MITIGATOR, it is usually necessary to remove the BGP announcements when connectivity with bordering routers is lost.\ By default, with the L3-router network deployment scheme, announcement via BGP can only occur if the bordering routers of the external and internal networks are allowed on MITIGATOR router_mac. In case of loss of connectivity with any of them, announcements are removed. However, in some cases it is required to continue BGP announcements even if bordering routers fail, for which following should be specified in the docker-compose.yml file: