https://docs.mitigator.ru/v26.04/en/tags/network-integration/ Recent content in Network Integration on BIFIT Mitigator Hugo -- gohugo.io en https://docs.mitigator.ru/v26.04/en/kb/deploy/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/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. Traffic from the external network – traffic coming to MITIGATOR from the external network. Consists of attack traffic and legitimate traffic. https://docs.mitigator.ru/v26.04/en/install/multi/workers/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/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. https://docs.mitigator.ru/v26.04/en/install/multi/failover/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/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. https://docs.mitigator.ru/v26.04/en/install/multi/custom/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/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. https://docs.mitigator.ru/v26.04/en/install/multi/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/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. https://docs.mitigator.ru/v26.04/en/install/multi/hybrid/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/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. For correct system operation all packet processors must have the same amount of system resources available. https://docs.mitigator.ru/v26.04/en/kb/bypass/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/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. https://docs.mitigator.ru/v26.04/en/kb/bgp-state/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/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.