<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Signaling on BIFIT Mitigator</title>
    <link>https://docs.mitigator.ru/v26.04/en/tags/signaling/</link>
    <description>Recent content in Signaling on BIFIT Mitigator</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language><atom:link href="https://docs.mitigator.ru/v26.04/en/tags/signaling/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>BGP Interaction</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/bgp/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/bgp/</guid>
      <description>Info Update coming soon.
MITIGATOR supports various BGP communication scenarios. Each cluster instance can function as an independent BGP speaker, announce prefixes and send and receive FlowSpec rules.
Memo Information about all aspects of BGP interaction settings is given below.
Local BGP Parameters Local BGP parameters should be defined for each cluster instance and each instance must be given permission to establish BGP connections with its BGP neighbors.
BGP Neighbors MITIGATOR instances can establish BGP connections with other network devices defined in the system as BGP neighbors.</description>
    </item>
    <item>
      <title>BGP Signaling</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/bgp-signaling/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/bgp-signaling/</guid>
      <description>The article describes how MITIGATOR uses BGP for signaling upstream telecom operators or security service providers (MSSP).
Signaling Goals When MITIGATOR works as a perimeter protection against DDoS attacks, it can independently mitigate an attack up to total incoming bandwidth. To prevent the inbound channels from being saturated, coarse filtering can be enabled at upstream telecom operators or protection service providers.
MSSP use REST API, BGP, BGP FlowSpec and closed proprietary protocols for clients&amp;rsquo; signaling.</description>
    </item>
    <item>
      <title>Configuring Tiered Protection with MITIGATOR</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/echelon/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/echelon/</guid>
      <description>The most effective approach to DDoS protection is a tiered defense architecture, in which surgical filtering of traffic entering the protected network is performed by an on-premise device at the network border, while mitigation mechanisms at the upstream telecom operator level prevent the channel from being saturated.
Always on protection at the upstream telecom operator side can cause problems and negatively affect legitimate traffic, so it should be activated only when necessary.</description>
    </item>
    <item>
      <title>Managing BGP Announcements When the External Router is Inactive</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/bgp-state/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/bgp-state/</guid>
      <description>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.</description>
    </item>
  </channel>
</rss>